[admin-discuss] Re: Update on IETF 125 meeting network
Alan DeKok <alan.dekok@inkbridge.io> Thu, 12 February 2026 00:53 UTC
Return-Path: <alan.dekok@inkbridge.io>
X-Original-To: admin-discuss@mail2.ietf.org
Delivered-To: admin-discuss@mail2.ietf.org
Received: from localhost (localhost [127.0.0.1]) by mail2.ietf.org (Postfix) with ESMTP id 2F71AB5E2101 for <admin-discuss@mail2.ietf.org>; Wed, 11 Feb 2026 16:53:03 -0800 (PST)
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="QxZSJTm8"; dkim=pass (2048-bit key) header.d=inkbridge.io header.b="hizNk/5E"
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 5Sn1BYP4JS_X for <admin-discuss@mail2.ietf.org>; Wed, 11 Feb 2026 16:53:01 -0800 (PST)
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 655E7B5E20B5 for <admin-discuss@ietf.org>; Wed, 11 Feb 2026 16:53:01 -0800 (PST)
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=ePxXZtraYJ6c230pGW6PEwR16zmW9D9WmuT3wd5dCww=; b=QxZSJTm8zDg0wISiN1DGyg5+94 l6TVMPWQ1skCHZC/PeE4Qo/tQGs7U/xkl7DwqfHkigq+DYSQg83WwBHtKswULmb/2G1WBlbLGvrTl 7UkRn3pUwJR65ThDdgDB+7vd+aYQcxDagDhb9TBSTLih387tbWFUuev/esy/JD+DRqGevT0ElLHoR /hMv7hzAEa9NxaQzautBKQIknw2hjah/2VHAuMZ+VVnHDuMU4rdsH9+6yk4ogn0FHxhNrL8aBeUUO t6MJR6O64TpuvkUKV06ljr8fLL/kVSwDeqtAr1adH0bWF4er+irfjOKlFYeogLiTCB65cUm+VssWI x2Fxa0eA==;
Received: from mail.servers.fr.internal.networkradius.com ([192.168.42.56]:51276 helo=mail.networkradius.com) by mail2.networkradius.com with esmtp (Exim 4.97) (envelope-from <alan.dekok@inkbridge.io>) id 1vqKww-00000000CGI-2b5C; Thu, 12 Feb 2026 00:52:54 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=inkbridge.io; s=sep2024; t=1770857573; bh=ePxXZtraYJ6c230pGW6PEwR16zmW9D9WmuT3wd5dCww=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From; b=hizNk/5EOhoBHsDLF5SC8oDC1JroC1cs/JVideWygb36tPllNYZ99c7M+nCCDv1HA vTMCL1Uqiqaferoq/iq/SaQ2a0Qj6+7osQgjyRmlQ0r4FchIApKspLA7N4DzlGZb7W i8dkzlFiujKLOdo91IU65KqQDvMtSzuLBff1b0o0b0GGiEHlKGI5Qg48jTr4JHV6WD R1dipIKo6H3hDKONQEdWuskvOQHaGgx3R7Ix6JIyZe9ucTSgBpbDYPEGSnKi48aESg hMEJ4maagxgfQHPksA0LQpfLmIhduqeVSASo/Jwjz2L65/pgxDfK405s6cayFwUlb3 t0UU2TmzJsc2w==
Received: from smtpclient.apple (24-246-4-149.cable.teksavvy.com [24.246.4.149]) by mail.networkradius.com (Postfix) with ESMTPSA id C43A3180; Thu, 12 Feb 2026 00:52:52 +0000 (UTC)
Content-Type: multipart/signed; boundary="Apple-Mail=_F768C4B6-42F1-4363-A775-72CBB7CF210D"; 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: <6902ebc8-54eb-47de-b406-f8cd10ee43e0@cs.tcd.ie>
Date: Wed, 11 Feb 2026 19:52:40 -0500
Message-Id: <5279CE89-9159-40C0-B2EC-4E191F2F50B3@inkbridge.io>
References: <579C2497-7ACA-4D06-B39D-7E2566BF753A@staff.ietf.org> <CABcZeBNuBzr6YCoTEkFWmK7FyMDDYmX_jYRViasXq3bjNrC4Kw@mail.gmail.com> <9B540423-38B9-4BAB-AB5D-B2AC9FB430C6@staff.ietf.org> <CABcZeBOSTCgxK=jooDMewhfYXYOGEZPjgKihGdfx2mOeM+SnHg@mail.gmail.com> <6902ebc8-54eb-47de-b406-f8cd10ee43e0@cs.tcd.ie>
To: Stephen Farrell <stephen.farrell@cs.tcd.ie>
X-Mailer: Apple Mail (2.3826.700.81.1.4)
Message-ID-Hash: UIZIO3HU3C543FQWIC6VXXPWKE2ZUNSX
X-Message-ID-Hash: UIZIO3HU3C543FQWIC6VXXPWKE2ZUNSX
X-MailFrom: alan.dekok@inkbridge.io
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
CC: Eric Rescorla <ekr@rtfm.com>, Greg Wood <ghwood@staff.ietf.org>, admin-discuss@ietf.org
X-Mailman-Version: 3.3.9rc6
Precedence: list
Subject: [admin-discuss] Re: Update on IETF 125 meeting network
List-Id: Discussion list for IETF LLC administrative issues <admin-discuss.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/admin-discuss/Dn7sMczt5HLPlV-pNDoV73b9jpE>
List-Archive: <https://mailarchive.ietf.org/arch/browse/admin-discuss>
List-Help: <mailto:admin-discuss-request@ietf.org?subject=help>
List-Owner: <mailto:admin-discuss-owner@ietf.org>
List-Post: <mailto:admin-discuss@ietf.org>
List-Subscribe: <mailto:admin-discuss-join@ietf.org>
List-Unsubscribe: <mailto:admin-discuss-leave@ietf.org>
On Feb 11, 2026, at 6:07 PM, Stephen Farrell <stephen.farrell@cs.tcd.ie> wrote: > On 11/02/2026 17:35, Eric Rescorla wrote: >> To the best of your knowledge, will third parties >> be able to use the information we provide, potentially in concert with other >> data they could foreseeably gather, to associate IP traffic with specific >> users? > > Yes, IMO that is a question the answer to which ought be available to > people using the meeting network before they establish connections. I won't speak for the NOC, but I can give a short summary of the technology. I'll try to keep it straightforward, so it's at least not wrong. 802.1X authentication uses an identity. In this case, something provided by the IETF, such as "user1234@example.org <mailto:user1@example.org>". That identity goes into RADIUS, generally along with the MAC address of the authenticating device. This allows the RADIUS server to correlate the MAC address and identity. So long as that correlation isn't shared off-box, it's not easy for any third party to correlate the two bits of information. If the APs enable protection for management frames, then the 802.1X data can be protected at the Wi-Fi layer. Otherwise, it's literally broadcast publicly for everyone to see. Some access points can be configured to not send the device MAC address in the RADIUS packets. Whether or not this is possible depends on the APs which are used. The device then does DHCP, which of course correlates MAC address to IP address. That information is public, because anyone on the local network can do ARP scans. Depending on the access point configuration of the access point, there may be RADIUS accounting packets which contain the above identity, plus MAC address and any IP address which was assigned via DHCP. Since the IETF isn't doing billing, it's not important to do billing, and the stream of accounting packets can be administratively disabled. Over all, it's not immediately trivial to correlate the supplied identity with a public IP address. However... We can also assume that the local network will be available for everyone to use. Which means that it's trivial to scan / fingerprint all devices on the network, locate them physically, etc. In addition, many people will be carrying phones, which will broadcast bluetooth IDs, often including things like 'Alan's Google Pixel 10 Pro Fold'. If those phones are on WiFi, additional correlation is possible. Which means for me, I wouldn't worry much about correlation between IETF issued identity, personal name, and IP address. Any correlations between personal name and IP address are likely already possible, independent of whatever the IETF does. So the IETF supplying some information as required is likely to change the cost of obtaining the data, but is not likely to change the contents of the data itself. I would still recommend that the NOC keep the minimal legally required information, of course. Sad to say for business reasons, I won't be attending in person. Alan DeKok.
- [admin-discuss] Re: [125all] Update on IETF 125 m… Alan DeKok
- [admin-discuss] Re: Update on IETF 125 meeting ne… Eric Rescorla
- [admin-discuss] Re: [125all] Update on IETF 125 m… Greg Wood
- [admin-discuss] Re: Update on IETF 125 meeting ne… Greg Wood
- [admin-discuss] Re: Update on IETF 125 meeting ne… Eric Vyncke (evyncke)
- [admin-discuss] Re: Update on IETF 125 meeting ne… Eric Rescorla
- [admin-discuss] Re: Update on IETF 125 meeting ne… Stephen Farrell
- [admin-discuss] Re: Update on IETF 125 meeting ne… Alan DeKok
- [admin-discuss] Re: Update on IETF 125 meeting ne… George Michaelson
- [admin-discuss] Re: Update on IETF 125 meeting ne… Alan DeKok
- [admin-discuss] Re: Update on IETF 125 meeting ne… Eric Rescorla
- [admin-discuss] Re: Update on IETF 125 meeting ne… Greg Wood
- [admin-discuss] Re: Update on IETF 125 meeting ne… Eric Rescorla
- [admin-discuss] Re: Update on IETF 125 meeting ne… Jay Daley
- [admin-discuss] Re: Update on IETF 125 meeting ne… Eric Rescorla
- [admin-discuss] Re: Update on IETF 125 meeting ne… Jay Daley
- [admin-discuss] Re: Update on IETF 125 meeting ne… Barry Leiba
- [admin-discuss] Re: Update on IETF 125 meeting ne… Eric Rescorla
- [admin-discuss] Re: Update on IETF 125 meeting ne… Alan DeKok
- [admin-discuss] Re: Update on IETF 125 meeting ne… Stephen Farrell
- [admin-discuss] Re: Update on IETF 125 meeting ne… Livingood, Jason
- [admin-discuss] Re: Update on IETF 125 meeting ne… Alan DeKok
- [admin-discuss] Re: Update on IETF 125 meeting ne… John C Klensin
- [admin-discuss] Re: Update on IETF 125 meeting ne… Eric Vyncke (evyncke)
- [admin-discuss] Re: [125all] Update on IETF 125 m… Mirja Kuehlewind (IETF)
- [admin-discuss] Re: [125all] Update on IETF 125 m… Jay Daley