Re: [Captive-portals] [Int-area] Evaluate impact of MAC address randomization to IP applications

Derek Fawcus <dfawcus+lists-int-area@employees.org> Fri, 25 September 2020 15:09 UTC

Return-Path: <dfawcus@employees.org>
X-Original-To: captive-portals@ietfa.amsl.com
Delivered-To: captive-portals@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED9723A0E53; Fri, 25 Sep 2020 08:09:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FPazJcTGQzmb; Fri, 25 Sep 2020 08:09:49 -0700 (PDT)
Received: from clarinet.employees.org (clarinet.employees.org [198.137.202.74]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E0C273A0E43; Fri, 25 Sep 2020 08:09:43 -0700 (PDT)
Received: by clarinet.employees.org (Postfix, from userid 1736) id 26D644E11D75; Fri, 25 Sep 2020 15:09:43 +0000 (UTC)
Date: Fri, 25 Sep 2020 16:09:43 +0100
From: Derek Fawcus <dfawcus+lists-int-area@employees.org>
To: captive-portals@ietf.org, homenet@ietf.org, int-area@ietf.org
Message-ID: <20200925150943.GA26109@clarinet.employees.org>
References: <20200922201317.097C3389D4@tuna.sandelman.ca> <15660.1600807202@localhost> <08df01d69124$49ab1f90$dd015eb0$@akayla.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <08df01d69124$49ab1f90$dd015eb0$@akayla.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/captive-portals/NoZWv4dp6uQR29LyCP7HxNtypcU>
Subject: Re: [Captive-portals] [Int-area] Evaluate impact of MAC address randomization to IP applications
X-BeenThere: captive-portals@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Discussion of issues related to captive portals <captive-portals.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/captive-portals>, <mailto:captive-portals-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/captive-portals/>
List-Post: <mailto:captive-portals@ietf.org>
List-Help: <mailto:captive-portals-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/captive-portals>, <mailto:captive-portals-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 25 Sep 2020 15:09:52 -0000

On Tue, Sep 22, 2020 at 02:06:48PM -0700, Peter Yee wrote:
> I believe that the address randomization (Private Address) can be turned off in iOS 14,
> but it seems to be a manual operation per ESSID only.

Sort of yes and no.

I happened to notice it this morning, having got IOS 14 on a device.
There is a manual configuration knob, it defaults to on.

Despite that it did (eventually) detect that the network does not support randomization,
and operationally disabled it, with a warning message about the privacy feature
being disabled or incompatible with the network, but with the 'private address' being
the built in MAC address.  Or at least it did initially before I manually disabled
the randomisation after noticing the warning, now it seems to only operate as a
manual on/off knob with no fallback operational disabling.

Also I happen to have a LAN, with 3 ESSIDs operating on it.
All currently using MAC filtering (yeah I know they can be spoofed).

Apple have a document describing what they desire for WiFi:
   https://support.apple.com/en-gb/HT202068

Where amongst other things, they mention not using different SSIDs for
different frequencies on the same LAN.

I guess the issue here is that when roaming between ESSIDs they'll change MAC,
affecting DHCP allocations and/or SLAAC and thereby break ongoing IP connectivity,
or force ARP and/or NDP re-resolution.

I'll have a go at disabling the MAC filter at some point,
and see how that affects the roaming behaviour.
Given the prevalence of broken NATs, I suspect lots of apps will just recover,
at worst after a delay.

DF