Re: [WIRELESS-LAN] MAC Randomization, a step further...

[Norman Elton]

Just a Friday afternoon update ...

I upgraded to Beta 4, and noticed that I was back to my physical MAC
address. This was also the case when I first went from iOS 13 to Beta 3, it
took a few days to start randomizing my address. I’ll keep an eye on things
over the next few days and let you know what I find out.

Norman



On Thu, Aug 6, 2020 at 8:05 PM Turner, Ryan H 
wrote:

> Are you referring to the serial?   Would Chad be willing to post his ulang
> for thr freeRadius config?
>
> Ryan Turner
> Head of Networking, ITS
> The University of North Carolina at Chapel Hill
> +1 919 274 7926 Mobile
> +1 919 445 0113 Office
>
> On Aug 6, 2020, at 5:02 PM, Philippe Hanset <
> 005cd62f91b7-dmarc-requ...@listserv.educause.edu> wrote:
>
>  About EAP-TLS blocking ...
>
> You do not need to revoke a cert (too painful indeed for operator and
> user). Chad wrote a hook for the Anyroam service that identifies the
> certificate’s fingerprint. So If a device misbehaves, you can just block
> the device via the certificate’s fingerprint. With one certificate per
> device, you end up with the same as a SIM card (or the good ol MAC address
> :)
>
> Philippe Hanset, CEO
> ANYROAM LLC
> www.anyroam.net
> www.eduroam.us
> +1 (865) 236-0770
>
> On Aug 6, 2020, at 11:29 AM, Turner, Ryan H 
> wrote:
>
> 
>
> The other issue comes in with blocking devices.  On open networks/PSK
> networks, this will make isolating bad devices really difficult.  We have
> relied on MAC address blocks for over a decade.  They work very well.  Yes,
> you can get a determined individual that can get past/change their MAC
> address.  But that is going to be a tiny fraction of cases, and MAC
> blocking is an effective way of blocking a bad device.
>
>
>
> We require registration for our PSK network.  So the private MAC addresses
> will be blocked effectively there.  But we haven’t required registration on
> eduroam (our primary), because we have identity in the certificate.  We
> chose not to use OCSP (but we can), but if we revoke a cert, we have to
> also block the user from getting another certificate (2 steps, instead of
> one, which is why we have stayed with MAC blocking).  We could require
> folks to register for eduroam, but that is such a nasty thing to do to the
> users.   Gr.  Not an easy fix.
>
>
>
> Ryan
>
>
>
> *From:* The EDUCAUSE Wireless Issues Community Group Listserv <
> WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU> *On Behalf Of *Enfield, Chuck
> *Sent:* Thursday, August 6, 2020 11:14 AM
> *To:* WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
> *Subject:* Re: [WIRELESS-LAN] MAC Randomization, a step further...
>
>
>
> I’ll also add that identity is what makes a private network private.  Yes,
> you can check identity at connection time then throw it away and still
> remain private, but that’s never been an option for us when designing
> services with our risk, legal and info security departments.
>
>
>
> *From:* The EDUCAUSE Wireless Issues Community Group Listserv <
> WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU> *On Behalf Of *Julian Y Koh
> *Sent:* Thursday, August 06, 2020 10:59 AM
> *To:* WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
> *Subject:* Re: [WIRELESS-LAN] MAC Randomization, a step further...
>
>
>
> On Aug 6, 2020, at 09:51, Enfield, Chuck  wrote:
>
>
>
> How can we fulfill DMCA requirements when we can’t even identify a device,
> let alone the user?  If you want to remain anonymous, use a different
> network.
>
>
>
> IANAL, and I don’t even play one on TV, but my admittedly old
> understanding of the DMCA is that it’s not necessarily mandating that you
> have to be able to identify every single device on your network.  Indeed,
> some institutions’ responses to DMCA notices has been that they don’t have
> the necessary information to be able to take action.  So IMO, assuming
> (which is dangerous) that I’m correct, that if MAC randomization puts an
> undue burden and/or large obstacles on your ability to track down a
> device/user and cut it off from the network, the DMCA alone shouldn’t be
> seen as a mandate to try to disable MAC randomization.
>
>
> --
>
> Julian Y. Koh
>
> Associate Director, Telecommunications and Network Services
>
> Northwestern Information Technology
>
> <https://www.google.com/maps/search/2020+Ridge+Avenue+%23331+%0D%0A+%0D%0A+%0D%0A+Evanston,+IL+60208?entry=gmail=g>
>
> <https://www.google.com/maps/search/2020+Ridge+Avenue+%23331+%0D%0A+%0D%0A+%0D%0A+Evanston,+IL+60208?entry=gmail=g>
>
>
>
> <https://www.google.com/maps/search/2020+Ridge+Avenue+%23331+%0D%0A+%0D%0A+%0D%0A+Evanston,+IL+60208?entry=gmail=g>
>
> 2020 Ridge Avenue #331
> <https

Re: [WIRELESS-LAN] MAC Randomization, a step further...

[Turner, Ryan H]

Are you referring to the serial?   Would Chad be willing to post his ulang for 
thr freeRadius config?

Ryan Turner
Head of Networking, ITS
The University of North Carolina at Chapel Hill
+1 919 274 7926 Mobile
+1 919 445 0113 Office

On Aug 6, 2020, at 5:02 PM, Philippe Hanset 
<005cd62f91b7-dmarc-requ...@listserv.educause.edu> wrote:

 About EAP-TLS blocking ...
You do not need to revoke a cert (too painful indeed for operator and user). 
Chad wrote a hook for the Anyroam service that identifies the certificate’s 
fingerprint. So If a device misbehaves, you can just block the device via the 
certificate’s fingerprint. With one certificate per device, you end up with the 
same as a SIM card (or the good ol MAC address :)

Philippe Hanset, CEO
ANYROAM LLC
www.anyroam.net
www.eduroam.us
+1 (865) 236-0770

On Aug 6, 2020, at 11:29 AM, Turner, Ryan H  wrote:


The other issue comes in with blocking devices.  On open networks/PSK networks, 
this will make isolating bad devices really difficult.  We have relied on MAC 
address blocks for over a decade.  They work very well.  Yes, you can get a 
determined individual that can get past/change their MAC address.  But that is 
going to be a tiny fraction of cases, and MAC blocking is an effective way of 
blocking a bad device.

We require registration for our PSK network.  So the private MAC addresses will 
be blocked effectively there.  But we haven’t required registration on eduroam 
(our primary), because we have identity in the certificate.  We chose not to 
use OCSP (but we can), but if we revoke a cert, we have to also block the user 
from getting another certificate (2 steps, instead of one, which is why we have 
stayed with MAC blocking).  We could require folks to register for eduroam, but 
that is such a nasty thing to do to the users.   Gr.  Not an easy fix.

Ryan

From: The EDUCAUSE Wireless Issues Community Group Listserv 
 On Behalf Of Enfield, Chuck
Sent: Thursday, August 6, 2020 11:14 AM
To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
Subject: Re: [WIRELESS-LAN] MAC Randomization, a step further...

I’ll also add that identity is what makes a private network private.  Yes, you 
can check identity at connection time then throw it away and still remain 
private, but that’s never been an option for us when designing services with 
our risk, legal and info security departments.

From: The EDUCAUSE Wireless Issues Community Group Listserv 
mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>> 
On Behalf Of Julian Y Koh
Sent: Thursday, August 06, 2020 10:59 AM
To: 
WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU<mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>
Subject: Re: [WIRELESS-LAN] MAC Randomization, a step further...

On Aug 6, 2020, at 09:51, Enfield, Chuck 
mailto:cae...@psu.edu>> wrote:

How can we fulfill DMCA requirements when we can’t even identify a device, let 
alone the user?  If you want to remain anonymous, use a different network.

IANAL, and I don’t even play one on TV, but my admittedly old understanding of 
the DMCA is that it’s not necessarily mandating that you have to be able to 
identify every single device on your network.  Indeed, some institutions’ 
responses to DMCA notices has been that they don’t have the necessary 
information to be able to take action.  So IMO, assuming (which is dangerous) 
that I’m correct, that if MAC randomization puts an undue burden and/or large 
obstacles on your ability to track down a device/user and cut it off from the 
network, the DMCA alone shouldn’t be seen as a mandate to try to disable MAC 
randomization.

--
Julian Y. Koh
Associate Director, Telecommunications and Network Services
Northwestern Information Technology

2020 Ridge Avenue #331
Evanston, IL 60208
+1-847-467-5780
Northwestern IT Web Site: 
<http://www.it.northwestern.edu/<https://nam01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.it.northwestern.edu%2F=02%7C01%7Ccae104%40PSU.EDU%7Cbb94cb7e13a643e92b3c08d83a19517d%7C7cf48d453ddb4389a9c1c115526eb52e%7C0%7C0%7C637323227705623251=TnloADAw118uF8UF0WBRnfqL0fOJNgfjLMjQMtrTFKw%3D=0>>
PGP Public Key: 
<https://bt.ittns.northwestern.edu/julian/pgppubkey.html<https://nam01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbt.ittns.northwestern.edu%2Fjulian%2Fpgppubkey.html=02%7C01%7Ccae104%40PSU.EDU%7Cbb94cb7e13a643e92b3c08d83a19517d%7C7cf48d453ddb4389a9c1c115526eb52e%7C0%7C0%7C637323227705623251=YGp3QvGhzeuy4IA3ZXzhXNJlUJnQ%2FN%2Fl1Nk5tIQSakg%3D=0>>


**
Replies to EDUCAUSE Community Group emails are sent to the entire community 
list. If you want to reply only to the person who sent the message, copy and 
paste their email address and forward the email reply. Additional participation 
and subscription information can be found at 
https://www.educause.edu/community<https://nam01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.educause.edu%2Fcommunity=02%7C01%7Ccae104%40PSU.EDU%7Cbb94cb7e13a643e92b3c08d83a19517d%7C7cf48d453d

Re: [External] Re: [WIRELESS-LAN] MAC Randomization, a step further...

[Hunter Fuller]

Ryan,

We have a flag you can set that will hide you from the UAH directory and
cause us to never reveal that you're a student ("FERPA hold"). One can
assume that privacy-conscious students might set this flag. By that metric,
12% of our students are privacy-conscious.

HTH

--
Hunter Fuller (they)
Router Jockey
VBH Annex B-5
+1 256 824 5331

Office of Information Technology
The University of Alabama in Huntsville
Network Engineering


On Thu, Aug 6, 2020 at 6:03 PM Turner, Ryan H 
wrote:

> Personally this just doesn’t resonate to me.  How many students care about
> privacy concerns every time they sign up for the latest social data mining
> app?
>
> Ryan Turner
> Head of Networking, ITS
> The University of North Carolina at Chapel Hill
> +1 919 274 7926 Mobile
> +1 919 445 0113 Office
>
> On Aug 6, 2020, at 3:36 PM, Tim Cappalli <
> 0194c9ecac40-dmarc-requ...@listserv.educause.edu> wrote:
>
> 
>
> Sure, everyone has their motives for privacy. But tracking a device by MAC
> address across networks is a huge and very real issue. Think about
> everywhere you see the XFINITY SSID. Every Comcast cable modem in the
> country broadcasts it. What a massive tracking domain if you have it saved
> on your phone. Those are the things Google and Apple are trying to prevent.
> Has really nothing to do with their own internal platform operation.
>
>
>
> That is why just setting a MAC per-SSID doesn’t cut it. But as per usual,
> the networking industry didn’t take this seriously 5+ years ago and OS
> vendors now have to back out of privacy preserving changes or face
> ridiculous (and IMO unnecessary) backlash.
>
>
>
> tim
>
>
>
> *From: *The EDUCAUSE Wireless Issues Community Group Listserv <
> WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>
> *Date: *Thursday, August 6, 2020 at 15:26
> *To: *WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU <
> WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>
> *Subject: *Re: [WIRELESS-LAN] MAC Randomization, a step further...
>
> Our lawyers tell me that we’re responsible for takedowns by virtue of it
> being on our network.  If the content is on host we manage we would just
> remove the content, but If it’s not our host, which is usually the case,
> then we have to remove the host from the network.
>
>
>
> FWIW, I’m not losing sleep over the liability issue.  We’re not putting
> the MAC auth genie back in the bottle any time soon, so the university is
> just going to live with that risk until we have a better option.  Besides,
> since we got a border firewall, takedowns have become really rare.  I’m
> more concerned about providing a quality connection and support experience
> for our users and getting compromised devices off the network.  The point
> of my original comment wasn’t really to debate DMCA, but to challenge Tim’s
> objection to disabling privacy settings.  There are good reasons to disable
> them for our networks on a per SSID basis, and if our users want to use the
> MAC auth network in the res halls, that’s what they’ll have to do.
>
>
>
> I also find it ironic that Apple and Google pretend to care about our
> privacy.  What they care about is our perception of their products.  If
> they actually cared about our privacy they would collect far less of our
> data than they do.  I’m not offended by it, but my position is
> fundamentally the same as theirs – if you’re unwilling to sacrifice your
> privacy, don’t use our stuff.
>
>
>
> *From:* The EDUCAUSE Wireless Issues Community Group Listserv <
> WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU> *On Behalf Of *Jeffrey D. Sessler
> *Sent:* Thursday, August 06, 2020 2:36 PM
> *To:* WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
> *Subject:* Re: [WIRELESS-LAN] MAC Randomization, a step further...
>
>
>
> Chuck,
>
>
>
> What DMCA requirements do you speak of?  As an ISP there is very little we
> technically have to do, but many EDU’s go above and beyond the
> requirements.  We have far more requirements if copyrighted information is
> being hosted on systems we own, but when it’s an end-user, there are little
> to no obligations, and if MAC address randomization makes it impossible,
> then there is nothing more one has to do under the DMCA.
>
>
>
> Jeff
>
>
>
> *From: *The EDUCAUSE Wireless Issues Community Group Listserv <
> WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>
> *Date: *Thursday, August 6, 2020 at 7:52 AM
> *To: *WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU <
> WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>
> *Subject: *Re: [WIRELESS-LAN] MAC Randomization, a step further...
>
> How can we fulfill DMCA requirements when we can’t even identify a device,
> let alone the user?  If you want to remain anonymous, use a different
> network.
>
&g

Re: [WIRELESS-LAN] MAC Randomization, a step further...

[Philippe Hanset]

About EAP-TLS blocking ...
You do not need to revoke a cert (too painful indeed for operator and user). 
Chad wrote a hook for the Anyroam service that identifies the certificate’s 
fingerprint. So If a device misbehaves, you can just block the device via the 
certificate’s fingerprint. With one certificate per device, you end up with the 
same as a SIM card (or the good ol MAC address :)

Philippe Hanset, CEO
ANYROAM LLC
www.anyroam.net
www.eduroam.us
+1 (865) 236-0770

On Aug 6, 2020, at 11:29 AM, Turner, Ryan H  wrote:


The other issue comes in with blocking devices.  On open networks/PSK networks, 
this will make isolating bad devices really difficult.  We have relied on MAC 
address blocks for over a decade.  They work very well.  Yes, you can get a 
determined individual that can get past/change their MAC address.  But that is 
going to be a tiny fraction of cases, and MAC blocking is an effective way of 
blocking a bad device.
 
We require registration for our PSK network.  So the private MAC addresses will 
be blocked effectively there.  But we haven’t required registration on eduroam 
(our primary), because we have identity in the certificate.  We chose not to 
use OCSP (but we can), but if we revoke a cert, we have to also block the user 
from getting another certificate (2 steps, instead of one, which is why we have 
stayed with MAC blocking).  We could require folks to register for eduroam, but 
that is such a nasty thing to do to the users.   Gr.  Not an easy fix.
 
Ryan
 
From: The EDUCAUSE Wireless Issues Community Group Listserv 
 On Behalf Of Enfield, Chuck
Sent: Thursday, August 6, 2020 11:14 AM
To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
Subject: Re: [WIRELESS-LAN] MAC Randomization, a step further...
 
I’ll also add that identity is what makes a private network private.  Yes, you 
can check identity at connection time then throw it away and still remain 
private, but that’s never been an option for us when designing services with 
our risk, legal and info security departments.
 
From: The EDUCAUSE Wireless Issues Community Group Listserv 
 On Behalf Of Julian Y Koh
Sent: Thursday, August 06, 2020 10:59 AM
To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
Subject: Re: [WIRELESS-LAN] MAC Randomization, a step further...
 
On Aug 6, 2020, at 09:51, Enfield, Chuck  wrote:
 
How can we fulfill DMCA requirements when we can’t even identify a device, let 
alone the user?  If you want to remain anonymous, use a different network.
 
IANAL, and I don’t even play one on TV, but my admittedly old understanding of 
the DMCA is that it’s not necessarily mandating that you have to be able to 
identify every single device on your network.  Indeed, some institutions’ 
responses to DMCA notices has been that they don’t have the necessary 
information to be able to take action.  So IMO, assuming (which is dangerous) 
that I’m correct, that if MAC randomization puts an undue burden and/or large 
obstacles on your ability to track down a device/user and cut it off from the 
network, the DMCA alone shouldn’t be seen as a mandate to try to disable MAC 
randomization.  

-- 
Julian Y. Koh
Associate Director, Telecommunications and Network Services
Northwestern Information Technology
 
2020 Ridge Avenue #331
Evanston, IL 60208
+1-847-467-5780
Northwestern IT Web Site: <http://www.it.northwestern.edu/>
PGP Public Key: <https://bt.ittns.northwestern.edu/julian/pgppubkey.html>
 
**
Replies to EDUCAUSE Community Group emails are sent to the entire community 
list. If you want to reply only to the person who sent the message, copy and 
paste their email address and forward the email reply. Additional participation 
and subscription information can be found at https://www.educause.edu/community

**
Replies to EDUCAUSE Community Group emails are sent to the entire community 
list. If you want to reply only to the person who sent the message, copy and 
paste their email address and forward the email reply. Additional participation 
and subscription information can be found at https://www.educause.edu/community

**
Replies to EDUCAUSE Community Group emails are sent to the entire community 
list. If you want to reply only to the person who sent the message, copy and 
paste their email address and forward the email reply. Additional participation 
and subscription information can be found at https://www.educause.edu/community
**
Replies to EDUCAUSE Community Group emails are sent to the entire community 
list. If you want to reply only to the person who sent the message, copy and 
paste their email address and forward the email reply. Additional participation 
and subscription information can be found at https://www.educause.edu/community

Re: [WIRELESS-LAN] MAC Randomization, a step further...

[Philippe Hanset]

For local users with 802.1X you can disable username authentication and for 
roaming users with 802.1X, Hopefully CUI (Chargeable User Identity) will become 
more mainstream and you can block by CUI (Needs to be supported in RADIUS).
 MAC address was never designed to identify, but we all found it very useful 
for that purpose :)... time to change !

Philippe Hanset, CEO
ANYROAM LLC
www.anyroam.net
www.eduroam.us
+1 (865) 236-0770

On Aug 6, 2020, at 11:03 AM, Tim Cappalli 
<0194c9ecac40-dmarc-requ...@listserv.educause.edu> wrote:


And you can continue to do that with the randomized MAC and tell them you took 
action against the device identifier that was presented at the time in 
question. Nothing changes in that regard 
 
Julian’s response is my understanding as well.
 
From: The EDUCAUSE Wireless Issues Community Group Listserv 

Date: Thursday, August 6, 2020 at 11:00
To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU 
Subject: Re: [WIRELESS-LAN] MAC Randomization, a step further...

We could always take down a device by MAC address.  It was weak, but it allowed 
us to say we did something.
 
From: The EDUCAUSE Wireless Issues Community Group Listserv 
 On Behalf Of Tim Cappalli
Sent: Thursday, August 06, 2020 10:55 AM
To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
Subject: Re: [WIRELESS-LAN] MAC Randomization, a step further...
 
Not sure how this really changes anything if you never had a strong user 
identity in the first place.
 
 
From: The EDUCAUSE Wireless Issues Community Group Listserv 

Date: Thursday, August 6, 2020 at 10:51
To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU 
Subject: Re: [WIRELESS-LAN] MAC Randomization, a step further...

How can we fulfill DMCA requirements when we can’t even identify a device, let 
alone the user?  If you want to remain anonymous, use a different network.
 
From: The EDUCAUSE Wireless Issues Community Group Listserv 
 On Behalf Of Tim Cappalli
Sent: Thursday, August 06, 2020 10:45 AM
To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
Subject: Re: [WIRELESS-LAN] MAC Randomization, a step further...
 
Yikes. I hope network operators are not asking users to disable user privacy 
protections. That is a slippery slope.
 
tim
 
From: The EDUCAUSE Wireless Issues Community Group Listserv 

Date: Thursday, August 6, 2020 at 10:40
To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU 
Subject: Re: [WIRELESS-LAN] MAC Randomization, a step further...

Was sent this link yesterday, might help some.
 
https://community.cisco.com/t5/security-documents/random-mac-address-how-to-deal-with-it-using-ise/ta-p/4049321
 
 
Blake Brown
Infrastructure Manager - MHCC
 
 
From: The EDUCAUSE Wireless Issues Community Group Listserv 
 on behalf of Norman Elton 

Sent: Thursday, August 6, 2020 5:48 AM
To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU 
Subject: Re: [WIRELESS-LAN] MAC Randomization, a step further...
 
External Email

>> I have heard that on the latest beta that came out Tuesday the randomization 
>> will only happen once per SSID and not change as well.
 
Oh? We will definitely be testing that. Can you share your source? My phone is 
still on Beta 3, and I don't have an update available for Beta 4 yet. I suppose 
I have to wait for my ticket to ride.
 
Thanks for the tip,
 
Norman
 
On Thu, Aug 6, 2020 at 6:55 AM Walter Reynolds  wrote:
I have heard that on the latest beta that came out Tuesday the randomization 
will only happen once per SSID and not change as well.


Walter Reynolds
Network Architect
Information and Technology Services
University of Michigan
(734) 615-9438
 
On Wed, Aug 5, 2020, 9:09 PM Norman Elton  wrote:
>> Depending on your tolerance for the disruption you could implement a network 
>> access policy blocking access to the
>> range of local MAC's and intercept with a captive portal with instructions 
>> on how to turn this off. However, I can't imagine
>> this being sustainable.
 
Newer Androids use the same MAC address range for their randomization 
algorithm. Unlike iOS; however, their MAC address is randomized once per SSID, 
and doesn't change over time. We already see a large number of private mac 
addresses on our campus, I anecdotally confirmed a handful of them are Android 
users, and confirmed the MAC remains consistent.
 
Long story short, if you're looking to restrict randomized MAC addresses, or 
even report on their usage, you'll find more than just iOS users :-/
 
There is a fine line between "troubleshooting" and "tracking". Unfortunately, 
preventing malicious tracking is going to impact our helpful troubleshooting. 
As an EAP-TLS campus, we're going to attempt to de-dupe the randomized MAC 
addresses using the certificate serial number. This way, if someone calls on 
Monday to complain about a problem on Saturday, at least we have someplace to 
start.
 
Norman
 
 
On Mon, Aug 3, 2020 at 10:28 AM John Turner  wrote:
Update on my testing. 
 
I created an 802.1X network and connected my ios14 phon

RE: [WIRELESS-LAN] MAC Randomization, a step further...

[Turner, Ryan H]

The other issue comes in with blocking devices.  On open networks/PSK networks, 
this will make isolating bad devices really difficult.  We have relied on MAC 
address blocks for over a decade.  They work very well.  Yes, you can get a 
determined individual that can get past/change their MAC address.  But that is 
going to be a tiny fraction of cases, and MAC blocking is an effective way of 
blocking a bad device.

We require registration for our PSK network.  So the private MAC addresses will 
be blocked effectively there.  But we haven’t required registration on eduroam 
(our primary), because we have identity in the certificate.  We chose not to 
use OCSP (but we can), but if we revoke a cert, we have to also block the user 
from getting another certificate (2 steps, instead of one, which is why we have 
stayed with MAC blocking).  We could require folks to register for eduroam, but 
that is such a nasty thing to do to the users.   Gr.  Not an easy fix.

Ryan

From: The EDUCAUSE Wireless Issues Community Group Listserv 
 On Behalf Of Enfield, Chuck
Sent: Thursday, August 6, 2020 11:14 AM
To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
Subject: Re: [WIRELESS-LAN] MAC Randomization, a step further...

I’ll also add that identity is what makes a private network private.  Yes, you 
can check identity at connection time then throw it away and still remain 
private, but that’s never been an option for us when designing services with 
our risk, legal and info security departments.

From: The EDUCAUSE Wireless Issues Community Group Listserv 
mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>> 
On Behalf Of Julian Y Koh
Sent: Thursday, August 06, 2020 10:59 AM
To: 
WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU<mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>
Subject: Re: [WIRELESS-LAN] MAC Randomization, a step further...

On Aug 6, 2020, at 09:51, Enfield, Chuck 
mailto:cae...@psu.edu>> wrote:

How can we fulfill DMCA requirements when we can’t even identify a device, let 
alone the user?  If you want to remain anonymous, use a different network.

IANAL, and I don’t even play one on TV, but my admittedly old understanding of 
the DMCA is that it’s not necessarily mandating that you have to be able to 
identify every single device on your network.  Indeed, some institutions’ 
responses to DMCA notices has been that they don’t have the necessary 
information to be able to take action.  So IMO, assuming (which is dangerous) 
that I’m correct, that if MAC randomization puts an undue burden and/or large 
obstacles on your ability to track down a device/user and cut it off from the 
network, the DMCA alone shouldn’t be seen as a mandate to try to disable MAC 
randomization.

--
Julian Y. Koh
Associate Director, Telecommunications and Network Services
Northwestern Information Technology

2020 Ridge Avenue #331
Evanston, IL 60208
+1-847-467-5780
Northwestern IT Web Site: 
<http://www.it.northwestern.edu/<https://nam01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.it.northwestern.edu%2F=02%7C01%7Ccae104%40PSU.EDU%7Cbb94cb7e13a643e92b3c08d83a19517d%7C7cf48d453ddb4389a9c1c115526eb52e%7C0%7C0%7C637323227705623251=TnloADAw118uF8UF0WBRnfqL0fOJNgfjLMjQMtrTFKw%3D=0>>
PGP Public Key: 
<https://bt.ittns.northwestern.edu/julian/pgppubkey.html<https://nam01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbt.ittns.northwestern.edu%2Fjulian%2Fpgppubkey.html=02%7C01%7Ccae104%40PSU.EDU%7Cbb94cb7e13a643e92b3c08d83a19517d%7C7cf48d453ddb4389a9c1c115526eb52e%7C0%7C0%7C637323227705623251=YGp3QvGhzeuy4IA3ZXzhXNJlUJnQ%2FN%2Fl1Nk5tIQSakg%3D=0>>


**
Replies to EDUCAUSE Community Group emails are sent to the entire community 
list. If you want to reply only to the person who sent the message, copy and 
paste their email address and forward the email reply. Additional participation 
and subscription information can be found at 
https://www.educause.edu/community<https://nam01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.educause.edu%2Fcommunity=02%7C01%7Ccae104%40PSU.EDU%7Cbb94cb7e13a643e92b3c08d83a19517d%7C7cf48d453ddb4389a9c1c115526eb52e%7C0%7C0%7C637323227705633208=jm59TBi7zaabxgoDYBcnnb6P5feRwtGIEIMnZOaDazM%3D=0>

**
Replies to EDUCAUSE Community Group emails are sent to the entire community 
list. If you want to reply only to the person who sent the message, copy and 
paste their email address and forward the email reply. Additional participation 
and subscription information can be found at https://www.educause.edu/community

**
Replies to EDUCAUSE Community Group emails are sent to the entire community 
list. If you want to reply only to the person who sent the message, copy and 
paste their email address and forward the email reply. Additional participation 
and subscription information can be found at https://www.educause.edu/community

RE: [WIRELESS-LAN] MAC Randomization, a step further...

[Enfield, Chuck]

I’ll also add that identity is what makes a private network private.  Yes, you 
can check identity at connection time then throw it away and still remain 
private, but that’s never been an option for us when designing services with 
our risk, legal and info security departments.

From: The EDUCAUSE Wireless Issues Community Group Listserv 
 On Behalf Of Julian Y Koh
Sent: Thursday, August 06, 2020 10:59 AM
To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
Subject: Re: [WIRELESS-LAN] MAC Randomization, a step further...

On Aug 6, 2020, at 09:51, Enfield, Chuck 
mailto:cae...@psu.edu>> wrote:

How can we fulfill DMCA requirements when we can’t even identify a device, let 
alone the user?  If you want to remain anonymous, use a different network.

IANAL, and I don’t even play one on TV, but my admittedly old understanding of 
the DMCA is that it’s not necessarily mandating that you have to be able to 
identify every single device on your network.  Indeed, some institutions’ 
responses to DMCA notices has been that they don’t have the necessary 
information to be able to take action.  So IMO, assuming (which is dangerous) 
that I’m correct, that if MAC randomization puts an undue burden and/or large 
obstacles on your ability to track down a device/user and cut it off from the 
network, the DMCA alone shouldn’t be seen as a mandate to try to disable MAC 
randomization.

--
Julian Y. Koh
Associate Director, Telecommunications and Network Services
Northwestern Information Technology

2020 Ridge Avenue #331
Evanston, IL 60208
+1-847-467-5780
Northwestern IT Web Site: 
<http://www.it.northwestern.edu/<https://nam01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.it.northwestern.edu%2F=02%7C01%7Ccae104%40PSU.EDU%7Cbb94cb7e13a643e92b3c08d83a19517d%7C7cf48d453ddb4389a9c1c115526eb52e%7C0%7C0%7C637323227705623251=TnloADAw118uF8UF0WBRnfqL0fOJNgfjLMjQMtrTFKw%3D=0>>
PGP Public Key: 
<https://bt.ittns.northwestern.edu/julian/pgppubkey.html<https://nam01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbt.ittns.northwestern.edu%2Fjulian%2Fpgppubkey.html=02%7C01%7Ccae104%40PSU.EDU%7Cbb94cb7e13a643e92b3c08d83a19517d%7C7cf48d453ddb4389a9c1c115526eb52e%7C0%7C0%7C637323227705623251=YGp3QvGhzeuy4IA3ZXzhXNJlUJnQ%2FN%2Fl1Nk5tIQSakg%3D=0>>


**
Replies to EDUCAUSE Community Group emails are sent to the entire community 
list. If you want to reply only to the person who sent the message, copy and 
paste their email address and forward the email reply. Additional participation 
and subscription information can be found at 
https://www.educause.edu/community<https://nam01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.educause.edu%2Fcommunity=02%7C01%7Ccae104%40PSU.EDU%7Cbb94cb7e13a643e92b3c08d83a19517d%7C7cf48d453ddb4389a9c1c115526eb52e%7C0%7C0%7C637323227705633208=jm59TBi7zaabxgoDYBcnnb6P5feRwtGIEIMnZOaDazM%3D=0>

**
Replies to EDUCAUSE Community Group emails are sent to the entire community 
list. If you want to reply only to the person who sent the message, copy and 
paste their email address and forward the email reply. Additional participation 
and subscription information can be found at https://www.educause.edu/community

Re: [WIRELESS-LAN] MAC Randomization, a step further...

[Blake Brown]

Good point Tim and that would be us. However we are getting ready to migrate to 
Meraki wireless this month, away from Cisco, and slowly reopening for some on 
campus classes. We didn't have some of the "tracking" functionality with our 
Cisco deployment but will with our Meraki.

COVID has thrown another requirement for "tracking" users on the campus which 
is currently done completely manually (paper) by the classroom instructors. I 
was hoping to automate some of this or at least be able to provide limited 
contact tracing information for a given period, longer than 24 hours, if 
requested.

Has anyone on the list worked through COVID contact tracing with their systems 
yet? If so what were some of the key takeaways you learned from it? Good and 
bad.


From: The EDUCAUSE Wireless Issues Community Group Listserv 
 on behalf of Enfield, Chuck 

Sent: Thursday, August 6, 2020 8:06 AM
To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU 
Subject: Re: [WIRELESS-LAN] MAC Randomization, a step further...

External Email


There are identity requests, and take downs.  Identity requests are frequent 
and come with little to know liability.  Take downs are less frequent, but 
failing to take down protected content makes the service provider liable.  Or 
plan for take downs when we can’t identify a user is to block the device.  If 
we can’t identify either we’ve got a liability problem.  It may not be a large 
risk, but I don’t think our lawyers will like it.



From: The EDUCAUSE Wireless Issues Community Group Listserv 
 On Behalf Of Julian Y Koh
Sent: Thursday, August 06, 2020 10:59 AM
To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
Subject: Re: [WIRELESS-LAN] MAC Randomization, a step further...



On Aug 6, 2020, at 09:51, Enfield, Chuck 
mailto:cae...@psu.edu>> wrote:



How can we fulfill DMCA requirements when we can’t even identify a device, let 
alone the user?  If you want to remain anonymous, use a different network.



IANAL, and I don’t even play one on TV, but my admittedly old understanding of 
the DMCA is that it’s not necessarily mandating that you have to be able to 
identify every single device on your network.  Indeed, some institutions’ 
responses to DMCA notices has been that they don’t have the necessary 
information to be able to take action.  So IMO, assuming (which is dangerous) 
that I’m correct, that if MAC randomization puts an undue burden and/or large 
obstacles on your ability to track down a device/user and cut it off from the 
network, the DMCA alone shouldn’t be seen as a mandate to try to disable MAC 
randomization.

--

Julian Y. Koh

Associate Director, Telecommunications and Network Services

Northwestern Information Technology



2020 Ridge Avenue #331

Evanston, IL 60208

+1-847-467-5780

Northwestern IT Web Site: 
<http://www.it.northwestern.edu/<https://nam01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.it.northwestern.edu%2F=02%7C01%7Ccae104%40PSU.EDU%7Cbb94cb7e13a643e92b3c08d83a19517d%7C7cf48d453ddb4389a9c1c115526eb52e%7C0%7C0%7C637323227705623251=TnloADAw118uF8UF0WBRnfqL0fOJNgfjLMjQMtrTFKw%3D=0>>

PGP Public Key: 
<https://bt.ittns.northwestern.edu/julian/pgppubkey.html<https://nam01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbt.ittns.northwestern.edu%2Fjulian%2Fpgppubkey.html=02%7C01%7Ccae104%40PSU.EDU%7Cbb94cb7e13a643e92b3c08d83a19517d%7C7cf48d453ddb4389a9c1c115526eb52e%7C0%7C0%7C637323227705623251=YGp3QvGhzeuy4IA3ZXzhXNJlUJnQ%2FN%2Fl1Nk5tIQSakg%3D=0>>



**
Replies to EDUCAUSE Community Group emails are sent to the entire community 
list. If you want to reply only to the person who sent the message, copy and 
paste their email address and forward the email reply. Additional participation 
and subscription information can be found at 
https://www.educause.edu/community<https://nam01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.educause.edu%2Fcommunity=02%7C01%7Ccae104%40PSU.EDU%7Cbb94cb7e13a643e92b3c08d83a19517d%7C7cf48d453ddb4389a9c1c115526eb52e%7C0%7C0%7C637323227705633208=jm59TBi7zaabxgoDYBcnnb6P5feRwtGIEIMnZOaDazM%3D=0>

**
Replies to EDUCAUSE Community Group emails are sent to the entire community 
list. If you want to reply only to the person who sent the message, copy and 
paste their email address and forward the email reply. Additional participation 
and subscription information can be found at https://www.educause.edu/community

**
Replies to EDUCAUSE Community Group emails are sent to the entire community 
list. If you want to reply only to the person who sent the message, copy and 
paste their email address and forward the email reply. Additional participation 
and subscription information can be found at https://www.educause.edu/community

RE: [WIRELESS-LAN] MAC Randomization, a step further...

[Enfield, Chuck]

There are identity requests, and take downs.  Identity requests are frequent 
and come with little to know liability.  Take downs are less frequent, but 
failing to take down protected content makes the service provider liable.  Or 
plan for take downs when we can’t identify a user is to block the device.  If 
we can’t identify either we’ve got a liability problem.  It may not be a large 
risk, but I don’t think our lawyers will like it.

From: The EDUCAUSE Wireless Issues Community Group Listserv 
 On Behalf Of Julian Y Koh
Sent: Thursday, August 06, 2020 10:59 AM
To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
Subject: Re: [WIRELESS-LAN] MAC Randomization, a step further...

On Aug 6, 2020, at 09:51, Enfield, Chuck 
mailto:cae...@psu.edu>> wrote:

How can we fulfill DMCA requirements when we can’t even identify a device, let 
alone the user?  If you want to remain anonymous, use a different network.

IANAL, and I don’t even play one on TV, but my admittedly old understanding of 
the DMCA is that it’s not necessarily mandating that you have to be able to 
identify every single device on your network.  Indeed, some institutions’ 
responses to DMCA notices has been that they don’t have the necessary 
information to be able to take action.  So IMO, assuming (which is dangerous) 
that I’m correct, that if MAC randomization puts an undue burden and/or large 
obstacles on your ability to track down a device/user and cut it off from the 
network, the DMCA alone shouldn’t be seen as a mandate to try to disable MAC 
randomization.

--
Julian Y. Koh
Associate Director, Telecommunications and Network Services
Northwestern Information Technology

2020 Ridge Avenue #331
Evanston, IL 60208
+1-847-467-5780
Northwestern IT Web Site: 
<http://www.it.northwestern.edu/<https://nam01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.it.northwestern.edu%2F=02%7C01%7Ccae104%40PSU.EDU%7Cbb94cb7e13a643e92b3c08d83a19517d%7C7cf48d453ddb4389a9c1c115526eb52e%7C0%7C0%7C637323227705623251=TnloADAw118uF8UF0WBRnfqL0fOJNgfjLMjQMtrTFKw%3D=0>>
PGP Public Key: 
<https://bt.ittns.northwestern.edu/julian/pgppubkey.html<https://nam01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbt.ittns.northwestern.edu%2Fjulian%2Fpgppubkey.html=02%7C01%7Ccae104%40PSU.EDU%7Cbb94cb7e13a643e92b3c08d83a19517d%7C7cf48d453ddb4389a9c1c115526eb52e%7C0%7C0%7C637323227705623251=YGp3QvGhzeuy4IA3ZXzhXNJlUJnQ%2FN%2Fl1Nk5tIQSakg%3D=0>>


**
Replies to EDUCAUSE Community Group emails are sent to the entire community 
list. If you want to reply only to the person who sent the message, copy and 
paste their email address and forward the email reply. Additional participation 
and subscription information can be found at 
https://www.educause.edu/community<https://nam01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.educause.edu%2Fcommunity=02%7C01%7Ccae104%40PSU.EDU%7Cbb94cb7e13a643e92b3c08d83a19517d%7C7cf48d453ddb4389a9c1c115526eb52e%7C0%7C0%7C637323227705633208=jm59TBi7zaabxgoDYBcnnb6P5feRwtGIEIMnZOaDazM%3D=0>

**
Replies to EDUCAUSE Community Group emails are sent to the entire community 
list. If you want to reply only to the person who sent the message, copy and 
paste their email address and forward the email reply. Additional participation 
and subscription information can be found at https://www.educause.edu/community

Re: [WIRELESS-LAN] MAC Randomization, a step further...

[Julian Y Koh]

On Aug 6, 2020, at 09:51, Enfield, Chuck 
mailto:cae...@psu.edu>> wrote:

How can we fulfill DMCA requirements when we can’t even identify a device, let 
alone the user?  If you want to remain anonymous, use a different network.

IANAL, and I don’t even play one on TV, but my admittedly old understanding of 
the DMCA is that it’s not necessarily mandating that you have to be able to 
identify every single device on your network.  Indeed, some institutions’ 
responses to DMCA notices has been that they don’t have the necessary 
information to be able to take action.  So IMO, assuming (which is dangerous) 
that I’m correct, that if MAC randomization puts an undue burden and/or large 
obstacles on your ability to track down a device/user and cut it off from the 
network, the DMCA alone shouldn’t be seen as a mandate to try to disable MAC 
randomization.

--
Julian Y. Koh
Associate Director, Telecommunications and Network Services
Northwestern Information Technology

2020 Ridge Avenue #331
Evanston, IL 60208
+1-847-467-5780
Northwestern IT Web Site: 
PGP Public Key: 


**
Replies to EDUCAUSE Community Group emails are sent to the entire community 
list. If you want to reply only to the person who sent the message, copy and 
paste their email address and forward the email reply. Additional participation 
and subscription information can be found at https://www.educause.edu/community

Re: [WIRELESS-LAN] MAC Randomization, a step further...

[Tim Cappalli]

I imagine the device is able to detect it is the same BSSID and determine the 
MAC does not need to be changed.

From: The EDUCAUSE Wireless Issues Community Group Listserv 
 on behalf of Rios, Hector J 

Sent: Friday, July 31, 2020 10:19
To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU 
Subject: Re: [WIRELESS-LAN] MAC Randomization, a step further...


Nope. MAC addr is still the same. This is day 2. I’ve been associated to the 
same AP.



Hector Rios, Wireless Network Architect

The University of Texas at Austin







From: The EDUCAUSE Wireless Issues Community Group Listserv 
 On Behalf Of Jake Snyder
Sent: Friday, July 31, 2020 8:54 AM
To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
Subject: Re: [WIRELESS-LAN] MAC Randomization, a step further...



It should change the next time it associates.

Sent from my iPhone



On Jul 30, 2020, at 1:02 PM, GT Hill mailto:g...@gthill.com>> 
wrote:



From what I understand it will keep the same MAC longer if it passing traffic 
at that 24 hour mark.



GT Hill



On Thu, Jul 30, 2020 at 1:44 PM Rios, Hector J 
mailto:hector.r...@austin.utexas.edu>> wrote:

I’ve done several tests on an iPhone 7 and there have been instances where the 
phone retains the same private MAC addr longer than 24 hours. Has anyone else 
done more testing?



Hector Rios, Wireless Network Architect

The University of Texas at Austin







From: The EDUCAUSE Wireless Issues Community Group Listserv 
mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>> 
On Behalf Of Enfield, Chuck
Sent: Friday, July 10, 2020 4:14 PM
To: 
WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU<mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>
Subject: Re: [WIRELESS-LAN] MAC Randomization, a step further...



Ahh.  I glossed right over the 24-hour part.  That’s much less distressing, but 
I’m going to have a beer anyway.



Thanks Tim.



From: The EDUCAUSE Wireless Issues Community Group Listserv 
mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>> 
On Behalf Of Tim Cappalli
Sent: Friday, July 10, 2020 5:04 PM
To: 
WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU<mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>
Subject: Re: [WIRELESS-LAN] MAC Randomization, a step further...



But why would that change anything? A user on campus for a football game is 
there for less than 24 hours. The MAC address changes per ESSID, every 24 
hours. I don’t understand what changes here for that use case?



It really only impacts mid to long term guests. So I guess in your example, 
parents weekend may be the one that is affected. But even then, dropping the 
lease times would solve the problem. I believe many wireless vendors recommend 
a visitor lease time of 1-8 hours.



From: The EDUCAUSE Wireless Issues Community Group Listserv 
mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>>
Date: Friday, July 10, 2020 at 17:01
To: 
WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU<mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU> 
mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>>
Subject: Re: [WIRELESS-LAN] MAC Randomization, a step further...

Tim,

With Covid, any lease time would not be an issue. But how big were your home 
football events / tailgate parties / parent weekends at Brandeis? I’m focusing 
more on the impact of those events on the guest side of things.

Brad



From: The EDUCAUSE Wireless Issues Community Group Listserv 
[mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU] On Behalf Of Tim Cappalli
Sent: Friday, July 10, 2020 3:53 PM
To: 
WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU<mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>
Subject: [EXTERNAL]Re: [WIRELESS-LAN] MAC Randomization, a step further...



Agreed on IPv6, but even for IPv4, I imagine most folks are running short 
leases on a visitor network, so I don’t really think much changes here. If your 
leases are 12 hours or less, there should be no impact.



tim



From: The EDUCAUSE Wireless Issues Community Group Listserv 
mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>>
Date: Friday, July 10, 2020 at 16:51
To: 
WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU<mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU> 
mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>>
Subject: Re: [WIRELESS-LAN] MAC Randomization, a step further...

Maybe a good use case for IPv6



From: The EDUCAUSE Wireless Issues Community Group Listserv 
[mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU] On Behalf Of Enfield, Chuck
Sent: Friday, July 10, 2020 3:49 PM
To: 
WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU<mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>
Subject: [EXTERNAL]Re: [WIRELESS-LAN] MAC Randomization, a step further...



Uhg.  Didn’t even think about that.



From: The EDUCAUSE Wireless Issues Community Group Listserv 
mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>> 
On Behalf Of Eric LaCroix
Sent: Friday, July 10, 2020 4:48 PM
To: 
WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU<mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>
Subject: Re: [WIRELESS-LAN] MAC Randomization, a step further...



We’re all going to need to check the TTL on DHCP l

RE: [WIRELESS-LAN] MAC Randomization, a step further...

[Rios, Hector J]

Nope. MAC addr is still the same. This is day 2. I’ve been associated to the 
same AP.

Hector Rios, Wireless Network Architect
The University of Texas at Austin



From: The EDUCAUSE Wireless Issues Community Group Listserv 
 On Behalf Of Jake Snyder
Sent: Friday, July 31, 2020 8:54 AM
To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
Subject: Re: [WIRELESS-LAN] MAC Randomization, a step further...

It should change the next time it associates.
Sent from my iPhone


On Jul 30, 2020, at 1:02 PM, GT Hill mailto:g...@gthill.com>> 
wrote:

From what I understand it will keep the same MAC longer if it passing traffic 
at that 24 hour mark.

GT Hill

On Thu, Jul 30, 2020 at 1:44 PM Rios, Hector J 
mailto:hector.r...@austin.utexas.edu>> wrote:
I’ve done several tests on an iPhone 7 and there have been instances where the 
phone retains the same private MAC addr longer than 24 hours. Has anyone else 
done more testing?

Hector Rios, Wireless Network Architect
The University of Texas at Austin



From: The EDUCAUSE Wireless Issues Community Group Listserv 
mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>> 
On Behalf Of Enfield, Chuck
Sent: Friday, July 10, 2020 4:14 PM
To: 
WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU<mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>
Subject: Re: [WIRELESS-LAN] MAC Randomization, a step further...

Ahh.  I glossed right over the 24-hour part.  That’s much less distressing, but 
I’m going to have a beer anyway.

Thanks Tim.

From: The EDUCAUSE Wireless Issues Community Group Listserv 
mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>> 
On Behalf Of Tim Cappalli
Sent: Friday, July 10, 2020 5:04 PM
To: 
WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU<mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>
Subject: Re: [WIRELESS-LAN] MAC Randomization, a step further...

But why would that change anything? A user on campus for a football game is 
there for less than 24 hours. The MAC address changes per ESSID, every 24 
hours. I don’t understand what changes here for that use case?

It really only impacts mid to long term guests. So I guess in your example, 
parents weekend may be the one that is affected. But even then, dropping the 
lease times would solve the problem. I believe many wireless vendors recommend 
a visitor lease time of 1-8 hours.

From: The EDUCAUSE Wireless Issues Community Group Listserv 
mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>>
Date: Friday, July 10, 2020 at 17:01
To: 
WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU<mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU> 
mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>>
Subject: Re: [WIRELESS-LAN] MAC Randomization, a step further...
Tim,
With Covid, any lease time would not be an issue. But how big were your home 
football events / tailgate parties / parent weekends at Brandeis? I’m focusing 
more on the impact of those events on the guest side of things.
Brad

From: The EDUCAUSE Wireless Issues Community Group Listserv 
[mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU] On Behalf Of Tim Cappalli
Sent: Friday, July 10, 2020 3:53 PM
To: 
WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU<mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>
Subject: [EXTERNAL]Re: [WIRELESS-LAN] MAC Randomization, a step further...

Agreed on IPv6, but even for IPv4, I imagine most folks are running short 
leases on a visitor network, so I don’t really think much changes here. If your 
leases are 12 hours or less, there should be no impact.

tim

From: The EDUCAUSE Wireless Issues Community Group Listserv 
mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>>
Date: Friday, July 10, 2020 at 16:51
To: 
WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU<mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU> 
mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>>
Subject: Re: [WIRELESS-LAN] MAC Randomization, a step further...
Maybe a good use case for IPv6

From: The EDUCAUSE Wireless Issues Community Group Listserv 
[mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU] On Behalf Of Enfield, Chuck
Sent: Friday, July 10, 2020 3:49 PM
To: 
WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU<mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>
Subject: [EXTERNAL]Re: [WIRELESS-LAN] MAC Randomization, a step further...

Uhg.  Didn’t even think about that.

From: The EDUCAUSE Wireless Issues Community Group Listserv 
mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>> 
On Behalf Of Eric LaCroix
Sent: Friday, July 10, 2020 4:48 PM
To: 
WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU<mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>
Subject: Re: [WIRELESS-LAN] MAC Randomization, a step further...

We’re all going to need to check the TTL on DHCP leases… some of our scopes 
will get eaten alive otherwise.

From: The EDUCAUSE Wireless Issues Community Group Listserv 
mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>> 
on behalf of "Floyd, Brad" mailto:bfl...@mail.smu.edu>>
Reply-To: The EDUCAUSE Wireless Issues Community Group Listserv 
mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>>
Date: Friday, July 10, 2020 at 3:42 PM
To: 
"WIRELESS-LAN@LISTSERV.EDUC

Re: [WIRELESS-LAN] MAC Randomization, a step further...

[David Logan]

Pondering... that implies that a heavyweight roaming event could change the
MAC.

 If true, that implies the WiFi roaming architecture considerations is even
more critical unless change of MAC doesn’t matter to the overall system
design and app behavior (I.e multimedia activity while physically roaming)

On Fri, Jul 31, 2020 at 9:54 AM Jake Snyder  wrote:

> It should change the next time it associates.
>
> Sent from my iPhone
>
> On Jul 30, 2020, at 1:02 PM, GT Hill  wrote:
>
> 
>
> From what I understand it will keep the same MAC longer if it passing
> traffic at that 24 hour mark.
>
> GT Hill
>
> On Thu, Jul 30, 2020 at 1:44 PM Rios, Hector J <
> hector.r...@austin.utexas.edu> wrote:
>
>> I’ve done several tests on an iPhone 7 and there have been instances
>> where the phone retains the same private MAC addr longer than 24 hours. Has
>> anyone else done more testing?
>>
>>
>>
>> Hector Rios, Wireless Network Architect
>>
>> The University of Texas at Austin
>>
>>
>>
>>
>>
>>
>>
>> *From:* The EDUCAUSE Wireless Issues Community Group Listserv <
>> WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU> *On Behalf Of *Enfield, Chuck
>> *Sent:* Friday, July 10, 2020 4:14 PM
>> *To:* WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
>> *Subject:* Re: [WIRELESS-LAN] MAC Randomization, a step further...
>>
>>
>>
>> Ahh.  I glossed right over the 24-hour part.  That’s much less
>> distressing, but I’m going to have a beer anyway.
>>
>>
>>
>> Thanks Tim.
>>
>>
>>
>> *From:* The EDUCAUSE Wireless Issues Community Group Listserv <
>> WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU> *On Behalf Of *Tim Cappalli
>> *Sent:* Friday, July 10, 2020 5:04 PM
>> *To:* WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
>> *Subject:* Re: [WIRELESS-LAN] MAC Randomization, a step further...
>>
>>
>>
>> But why would that change anything? A user on campus for a football
>> game is there for less than 24 hours. The MAC address changes per ESSID,
>> every 24 hours. I don’t understand what changes here for that use case?
>>
>>
>>
>> It really only impacts mid to long term guests. So I guess in your
>> example, parents weekend may be the one that is affected. But even then,
>> dropping the lease times would solve the problem. I believe many wireless
>> vendors recommend a visitor lease time of 1-8 hours.
>>
>>
>>
>> *From: *The EDUCAUSE Wireless Issues Community Group Listserv <
>> WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>
>> *Date: *Friday, July 10, 2020 at 17:01
>> *To: *WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU <
>> WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>
>> *Subject: *Re: [WIRELESS-LAN] MAC Randomization, a step further...
>>
>> Tim,
>>
>> With Covid, any lease time would not be an issue. But how big were your
>> home football events / tailgate parties / parent weekends at Brandeis? I’m
>> focusing more on the impact of those events on the guest side of things.
>>
>> Brad
>>
>>
>>
>> *From:* The EDUCAUSE Wireless Issues Community Group Listserv [
>> mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
>> ] *On Behalf Of *Tim Cappalli
>> *Sent:* Friday, July 10, 2020 3:53 PM
>> *To:* WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
>> *Subject:* [EXTERNAL]Re: [WIRELESS-LAN] MAC Randomization, a step
>> further...
>>
>>
>>
>> Agreed on IPv6, but even for IPv4, I imagine most folks are running short
>> leases on a visitor network, so I don’t really think much changes here. If
>> your leases are 12 hours or less, there should be no impact.
>>
>>
>>
>> tim
>>
>>
>>
>> *From: *The EDUCAUSE Wireless Issues Community Group Listserv <
>> WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>
>> *Date: *Friday, July 10, 2020 at 16:51
>> *To: *WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU <
>> WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>
>> *Subject: *Re: [WIRELESS-LAN] MAC Randomization, a step further...
>>
>> Maybe a good use case for IPv6
>>
>>
>>
>> *From:* The EDUCAUSE Wireless Issues Community Group Listserv [
>> mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
>> ] *On Behalf Of *Enfield, Chuck
>> *Sent:* Friday, July 10, 2020 3:49 PM
>> *To:* WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
>> *Subject:* [EXTERNAL]Re: [WIRELESS-LAN] MAC Randomization, a step
>> further...
>>
>>
>>
>> Uhg.  Didn’t even think about that.
>>
>>
>>
>> *From:* The EDUCAUSE Wireless Issues Community Group Listserv <
>> 

Re: [WIRELESS-LAN] MAC Randomization, a step further...

[Jake Snyder]

It should change the next time it associates.

Sent from my iPhone

> On Jul 30, 2020, at 1:02 PM, GT Hill  wrote:
> 
> 
> From what I understand it will keep the same MAC longer if it passing traffic 
> at that 24 hour mark. 
> 
> GT Hill
> 
>> On Thu, Jul 30, 2020 at 1:44 PM Rios, Hector J 
>>  wrote:
>> I’ve done several tests on an iPhone 7 and there have been instances where 
>> the phone retains the same private MAC addr longer than 24 hours. Has anyone 
>> else done more testing?
>> 
>>  
>> 
>> Hector Rios, Wireless Network Architect
>> 
>> The University of Texas at Austin
>> 
>>  
>> 
>>  
>> 
>>  
>> 
>> From: The EDUCAUSE Wireless Issues Community Group Listserv 
>>  On Behalf Of Enfield, Chuck
>> Sent: Friday, July 10, 2020 4:14 PM
>> To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
>> Subject: Re: [WIRELESS-LAN] MAC Randomization, a step further...
>> 
>>  
>> 
>> Ahh.  I glossed right over the 24-hour part.  That’s much less distressing, 
>> but I’m going to have a beer anyway.
>> 
>>  
>> 
>> Thanks Tim.
>> 
>>  
>> 
>> From: The EDUCAUSE Wireless Issues Community Group Listserv 
>>  On Behalf Of Tim Cappalli
>> Sent: Friday, July 10, 2020 5:04 PM
>> To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
>> Subject: Re: [WIRELESS-LAN] MAC Randomization, a step further...
>> 
>>  
>> 
>> But why would that change anything? A user on campus for a football game is 
>> there for less than 24 hours. The MAC address changes per ESSID, every 24 
>> hours. I don’t understand what changes here for that use case?
>> 
>>  
>> 
>> It really only impacts mid to long term guests. So I guess in your example, 
>> parents weekend may be the one that is affected. But even then, dropping the 
>> lease times would solve the problem. I believe many wireless vendors 
>> recommend a visitor lease time of 1-8 hours.
>> 
>>  
>> 
>> From: The EDUCAUSE Wireless Issues Community Group Listserv 
>> 
>> Date: Friday, July 10, 2020 at 17:01
>> To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU 
>> Subject: Re: [WIRELESS-LAN] MAC Randomization, a step further...
>> 
>> Tim,
>> 
>> With Covid, any lease time would not be an issue. But how big were your home 
>> football events / tailgate parties / parent weekends at Brandeis? I’m 
>> focusing more on the impact of those events on the guest side of things.
>> 
>> Brad
>> 
>>  
>> 
>> From: The EDUCAUSE Wireless Issues Community Group Listserv 
>> [mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU] On Behalf Of Tim Cappalli
>> Sent: Friday, July 10, 2020 3:53 PM
>> To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
>> Subject: [EXTERNAL]Re: [WIRELESS-LAN] MAC Randomization, a step further...
>> 
>>  
>> 
>> Agreed on IPv6, but even for IPv4, I imagine most folks are running short 
>> leases on a visitor network, so I don’t really think much changes here. If 
>> your leases are 12 hours or less, there should be no impact.
>> 
>>  
>> 
>> tim
>> 
>>  
>> 
>> From: The EDUCAUSE Wireless Issues Community Group Listserv 
>> 
>> Date: Friday, July 10, 2020 at 16:51
>> To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU 
>> Subject: Re: [WIRELESS-LAN] MAC Randomization, a step further...
>> 
>> Maybe a good use case for IPv6????
>> 
>>  
>> 
>> From: The EDUCAUSE Wireless Issues Community Group Listserv 
>> [mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU] On Behalf Of Enfield, Chuck
>> Sent: Friday, July 10, 2020 3:49 PM
>> To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
>> Subject: [EXTERNAL]Re: [WIRELESS-LAN] MAC Randomization, a step further...
>> 
>>  
>> 
>> Uhg.  Didn’t even think about that.
>> 
>>  
>> 
>> From: The EDUCAUSE Wireless Issues Community Group Listserv 
>>  On Behalf Of Eric LaCroix
>> Sent: Friday, July 10, 2020 4:48 PM
>> To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
>> Subject: Re: [WIRELESS-LAN] MAC Randomization, a step further...
>> 
>>  
>> 
>> We’re all going to need to check the TTL on DHCP leases… some of our scopes 
>> will get eaten alive otherwise.
>> 
>>  
>> 
>> From: The EDUCAUSE Wireless Issues Community Group Listserv 
>>  on behalf of "Floyd, Brad" 
>> 
>> Reply-To: The EDUCAUSE Wireless Issues Community Group Listserv 
>> 
>> Date: Friday, July 10, 2020 at 3:42 PM
>> To: "WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU"

Re: [WIRELESS-LAN] MAC Randomization, a step further...

[GT Hill]

>From what I understand it will keep the same MAC longer if it passing
traffic at that 24 hour mark.

GT Hill

On Thu, Jul 30, 2020 at 1:44 PM Rios, Hector J <
hector.r...@austin.utexas.edu> wrote:

> I’ve done several tests on an iPhone 7 and there have been instances where
> the phone retains the same private MAC addr longer than 24 hours. Has
> anyone else done more testing?
>
>
>
> Hector Rios, Wireless Network Architect
>
> The University of Texas at Austin
>
>
>
>
>
>
>
> *From:* The EDUCAUSE Wireless Issues Community Group Listserv <
> WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU> *On Behalf Of *Enfield, Chuck
> *Sent:* Friday, July 10, 2020 4:14 PM
> *To:* WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
> *Subject:* Re: [WIRELESS-LAN] MAC Randomization, a step further...
>
>
>
> Ahh.  I glossed right over the 24-hour part.  That’s much less
> distressing, but I’m going to have a beer anyway.
>
>
>
> Thanks Tim.
>
>
>
> *From:* The EDUCAUSE Wireless Issues Community Group Listserv <
> WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU> *On Behalf Of *Tim Cappalli
> *Sent:* Friday, July 10, 2020 5:04 PM
> *To:* WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
> *Subject:* Re: [WIRELESS-LAN] MAC Randomization, a step further...
>
>
>
> But why would that change anything? A user on campus for a football game
> is there for less than 24 hours. The MAC address changes per ESSID, every
> 24 hours. I don’t understand what changes here for that use case?
>
>
>
> It really only impacts mid to long term guests. So I guess in your
> example, parents weekend may be the one that is affected. But even then,
> dropping the lease times would solve the problem. I believe many wireless
> vendors recommend a visitor lease time of 1-8 hours.
>
>
>
> *From: *The EDUCAUSE Wireless Issues Community Group Listserv <
> WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>
> *Date: *Friday, July 10, 2020 at 17:01
> *To: *WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU <
> WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>
> *Subject: *Re: [WIRELESS-LAN] MAC Randomization, a step further...
>
> Tim,
>
> With Covid, any lease time would not be an issue. But how big were your
> home football events / tailgate parties / parent weekends at Brandeis? I’m
> focusing more on the impact of those events on the guest side of things.
>
> Brad
>
>
>
> *From:* The EDUCAUSE Wireless Issues Community Group Listserv [
> mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
> ] *On Behalf Of *Tim Cappalli
> *Sent:* Friday, July 10, 2020 3:53 PM
> *To:* WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
> *Subject:* [EXTERNAL]Re: [WIRELESS-LAN] MAC Randomization, a step
> further...
>
>
>
> Agreed on IPv6, but even for IPv4, I imagine most folks are running short
> leases on a visitor network, so I don’t really think much changes here. If
> your leases are 12 hours or less, there should be no impact.
>
>
>
> tim
>
>
>
> *From: *The EDUCAUSE Wireless Issues Community Group Listserv <
> WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>
> *Date: *Friday, July 10, 2020 at 16:51
> *To: *WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU <
> WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>
> *Subject: *Re: [WIRELESS-LAN] MAC Randomization, a step further...
>
> Maybe a good use case for IPv6
>
>
>
> *From:* The EDUCAUSE Wireless Issues Community Group Listserv [
> mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
> ] *On Behalf Of *Enfield, Chuck
> *Sent:* Friday, July 10, 2020 3:49 PM
> *To:* WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
> *Subject:* [EXTERNAL]Re: [WIRELESS-LAN] MAC Randomization, a step
> further...
>
>
>
> Uhg.  Didn’t even think about that.
>
>
>
> *From:* The EDUCAUSE Wireless Issues Community Group Listserv <
> WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU> *On Behalf Of *Eric LaCroix
> *Sent:* Friday, July 10, 2020 4:48 PM
> *To:* WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
> *Subject:* Re: [WIRELESS-LAN] MAC Randomization, a step further...
>
>
>
> We’re all going to need to check the TTL on DHCP leases… some of our
> scopes will get eaten alive otherwise.
>
>
>
> *From: *The EDUCAUSE Wireless Issues Community Group Listserv <
> WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU> on behalf of "Floyd, Brad" <
> bfl...@mail.smu.edu>
> *Reply-To: *The EDUCAUSE Wireless Issues Community Group Listserv <
> WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>
> *Date: *Friday, July 10, 2020 at 3:42 PM
> *To: *"WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU" <
> WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>
> *Subject: *Re: [WIRELESS-LAN] MAC Randomization, a step further...
>
>
>
> Thanks Tim. I just started a conversation with my SE.
>
> Brad
>
>
>
> *F

RE: [WIRELESS-LAN] MAC Randomization, a step further...

[Rios, Hector J]

I’ve done several tests on an iPhone 7 and there have been instances where the 
phone retains the same private MAC addr longer than 24 hours. Has anyone else 
done more testing?

Hector Rios, Wireless Network Architect
The University of Texas at Austin



From: The EDUCAUSE Wireless Issues Community Group Listserv 
 On Behalf Of Enfield, Chuck
Sent: Friday, July 10, 2020 4:14 PM
To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
Subject: Re: [WIRELESS-LAN] MAC Randomization, a step further...

Ahh.  I glossed right over the 24-hour part.  That’s much less distressing, but 
I’m going to have a beer anyway.

Thanks Tim.

From: The EDUCAUSE Wireless Issues Community Group Listserv 
mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>> 
On Behalf Of Tim Cappalli
Sent: Friday, July 10, 2020 5:04 PM
To: 
WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU<mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>
Subject: Re: [WIRELESS-LAN] MAC Randomization, a step further...

But why would that change anything? A user on campus for a football game is 
there for less than 24 hours. The MAC address changes per ESSID, every 24 
hours. I don’t understand what changes here for that use case?

It really only impacts mid to long term guests. So I guess in your example, 
parents weekend may be the one that is affected. But even then, dropping the 
lease times would solve the problem. I believe many wireless vendors recommend 
a visitor lease time of 1-8 hours.

From: The EDUCAUSE Wireless Issues Community Group Listserv 
mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>>
Date: Friday, July 10, 2020 at 17:01
To: 
WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU<mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU> 
mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>>
Subject: Re: [WIRELESS-LAN] MAC Randomization, a step further...
Tim,
With Covid, any lease time would not be an issue. But how big were your home 
football events / tailgate parties / parent weekends at Brandeis? I’m focusing 
more on the impact of those events on the guest side of things.
Brad

From: The EDUCAUSE Wireless Issues Community Group Listserv 
[mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU] On Behalf Of Tim Cappalli
Sent: Friday, July 10, 2020 3:53 PM
To: 
WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU<mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>
Subject: [EXTERNAL]Re: [WIRELESS-LAN] MAC Randomization, a step further...

Agreed on IPv6, but even for IPv4, I imagine most folks are running short 
leases on a visitor network, so I don’t really think much changes here. If your 
leases are 12 hours or less, there should be no impact.

tim

From: The EDUCAUSE Wireless Issues Community Group Listserv 
mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>>
Date: Friday, July 10, 2020 at 16:51
To: 
WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU<mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU> 
mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>>
Subject: Re: [WIRELESS-LAN] MAC Randomization, a step further...
Maybe a good use case for IPv6

From: The EDUCAUSE Wireless Issues Community Group Listserv 
[mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU] On Behalf Of Enfield, Chuck
Sent: Friday, July 10, 2020 3:49 PM
To: 
WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU<mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>
Subject: [EXTERNAL]Re: [WIRELESS-LAN] MAC Randomization, a step further...

Uhg.  Didn’t even think about that.

From: The EDUCAUSE Wireless Issues Community Group Listserv 
mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>> 
On Behalf Of Eric LaCroix
Sent: Friday, July 10, 2020 4:48 PM
To: 
WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU<mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>
Subject: Re: [WIRELESS-LAN] MAC Randomization, a step further...

We’re all going to need to check the TTL on DHCP leases… some of our scopes 
will get eaten alive otherwise.

From: The EDUCAUSE Wireless Issues Community Group Listserv 
mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>> 
on behalf of "Floyd, Brad" mailto:bfl...@mail.smu.edu>>
Reply-To: The EDUCAUSE Wireless Issues Community Group Listserv 
mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>>
Date: Friday, July 10, 2020 at 3:42 PM
To: 
"WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU<mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>" 
mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>>
Subject: Re: [WIRELESS-LAN] MAC Randomization, a step further...

Thanks Tim. I just started a conversation with my SE.
Brad

From: The EDUCAUSE Wireless Issues Community Group Listserv 
[mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU] On Behalf Of Tim Cappalli
Sent: Friday, July 10, 2020 2:07 PM
To: 
WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU<mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>
Subject: [EXTERNAL]Re: [WIRELESS-LAN] MAC Randomization, a step further...

For extended visitor use cases (over 1 day), Passpoint is really the only 
feasible solution moving forward. Aruba has a Passpoint offering/service called 
Air Pass and WBA’s OpenRoaming initiative is gaining a lot of support.

tim

From: The EDUCAUSE Wireless Iss

Re: [WIRELESS-LAN] MAC Randomization, a step further...

[Miller, Keith C]

Thanks for providing some examples John. It looks like you may have 2 SSIDs, 1 
per band. Did the MAC address also change for the “linksys55” SSID?

Reading from the published Apple document that Hector shared:

“To reduce this privacy risk, iOS 14, iPadOS 14, and watchOS 7 include a 
feature that periodically changes the MAC address your device uses with each 
Wi-Fi network. This randomized MAC address is your device's private Wi-Fi 
address for that network—until the next time it joins with a different address”

I really wish they would provide more detail about what “periodically” means 
and if this occurs at some specific interval depending on activity as some have 
suggested.

https://support.apple.com/en-us/HT211227


Regards,
Keith

From: The EDUCAUSE Wireless Issues Community Group Listserv 
 on behalf of John Turner 

Reply-To: The EDUCAUSE Wireless Issues Community Group Listserv 

Date: Tuesday, July 21, 2020 at 6:23 PM
To: "WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU" 
Subject: Re: [WIRELESS-LAN] MAC Randomization, a step further...

I’m working on testing this now.

So far it appears that the "Private Address" option is enabled by default for 
any of the "My Networks" and initially is set to the hardware MAC address.

New connections receive a new private MAC.

Toggling the WiFi does not change them.

I will update tomorrow on if it changes.

Here are 2 screenshots from my home network ( the F3:4D was configured prior to 
upgrade)

On Tue, Jul 21, 2020 at 6:15 PM Norman Elton 
mailto:normel...@gmail.com>> wrote:
This is all fascinating, I’m looking forward to getting my hands on a public 
beta.

Those “in the know” ... does this impact 1x networks as well as open? It seems 
that if you’re connecting with credentials, there’s already a trust 
relationship in place.

And is the feature enabled for networks that were configured before upgrading 
to iOS 14?

Fun times,

Norman Elton



On Tue, Jul 21, 2020 at 2:55 PM Rios, Hector J 
mailto:hector.r...@austin.utexas.edu>> wrote:
I just finished reading the “Apple Beta Software Program Agreement”. 
Interesting information:

“Don’t blog, post screen shots, tweet, or publicly post information about the 
public beta software, and don’t discuss the public beta software with or 
demonstrate it to others who are not in the Apple Beta Software Program.”

So, I need everyone to sign up to the beta software program so we can continue 
this conversation (J/K)

Hector Rios, Wireless Network Architect
The University of Texas at Austin



From: The EDUCAUSE Wireless Issues Community Group Listserv 
mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>> 
On Behalf Of Tim Cappalli
Sent: Tuesday, July 21, 2020 1:06 PM
To: 
WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU<mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>
Subject: Re: [WIRELESS-LAN] MAC Randomization, a step further...

Yeah, good catch Chris! I’d be interested in seeing some field data as well. 
The only info I saw was that it changed every 24 hours, but it sounds like 
there’s a * which indicates inactivity / not associated.

It makes much more sense that it wouldn’t change if the device maintains an 
active connection as there are really no privacy concerns until the device 
disconnects and moves.

tim

From: The EDUCAUSE Wireless Issues Community Group Listserv 
mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>>
Date: Tuesday, July 21, 2020 at 13:15
To: 
WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU<mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU> 
mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>>
Subject: Re: [WIRELESS-LAN] MAC Randomization, a step further...
Tim had mentioned the following: “On iOS 14, the MAC is set per ESSID and is 
changed once every 24 hours.”

Chris then mentioned that he found one iOS 14 device that, as long as it 
remains connected, the MAC remains the same, even beyond 24hrs.

Has anyone else done testing? Please share your results.

Hector Rios, Wireless Network Architect
The University of Texas at Austin



From: The EDUCAUSE Wireless Issues Community Group Listserv 
mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>> 
On Behalf Of Johnson, Christopher
Sent: Monday, July 20, 2020 10:19 AM
To: 
WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU<mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>
Subject: Re: [WIRELESS-LAN] MAC Randomization, a step further...

Default behavior matters indeed. Got a preview of what to expect over the 
weekend.

Found one individual that was in Aruba Airwave “12 Times” for their iPhone 14.0 
over past couple of weeks and another “6 times”. It appears that as long as the 
device remains “connected” to the network beyond the 24 hours, the MAC Address 
will remain the same. Although if they’re fully de-authenticated or move say 
into an elevator or outside (or a class phone reboot occurs in the pocket) – 
then the MAC Address will update upon establishing a new connection – that is 
just the initial observation I saw.
Christopher Johnson
Wireless Networ

Re: [WIRELESS-LAN] MAC Randomization, a step further...

[Tim Cappalli]

It should not affect 802.1X outside of potential database bloat if your policy 
engine stores MAC addresses.

I honestly can’t remember if it was enabled for existing saved networks post 
upgrade. Will be interesting to hear others experiences.

tim

From: The EDUCAUSE Wireless Issues Community Group Listserv 

Date: Tuesday, July 21, 2020 at 18:16
To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU 
Subject: Re: [WIRELESS-LAN] MAC Randomization, a step further...
This is all fascinating, I’m looking forward to getting my hands on a public 
beta.

Those “in the know” ... does this impact 1x networks as well as open? It seems 
that if you’re connecting with credentials, there’s already a trust 
relationship in place.

And is the feature enabled for networks that were configured before upgrading 
to iOS 14?

Fun times,

Norman Elton



On Tue, Jul 21, 2020 at 2:55 PM Rios, Hector J 
mailto:hector.r...@austin.utexas.edu>> wrote:
I just finished reading the “Apple Beta Software Program Agreement”. 
Interesting information:

“Don’t blog, post screen shots, tweet, or publicly post information about the 
public beta software, and don’t discuss the public beta software with or 
demonstrate it to others who are not in the Apple Beta Software Program.”

So, I need everyone to sign up to the beta software program so we can continue 
this conversation (J/K)

Hector Rios, Wireless Network Architect
The University of Texas at Austin



From: The EDUCAUSE Wireless Issues Community Group Listserv 
mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>> 
On Behalf Of Tim Cappalli
Sent: Tuesday, July 21, 2020 1:06 PM
To: 
WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU<mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>
Subject: Re: [WIRELESS-LAN] MAC Randomization, a step further...

 Yeah, good catch Chris! I’d be interested in seeing some field data as well. 
The only info I saw was that it changed every 24 hours, but it sounds like 
there’s a * which indicates inactivity / not associated.

It makes much more sense that it wouldn’t change if the device maintains an 
active connection as there are really no privacy concerns until the device 
disconnects and moves.

tim

From: The EDUCAUSE Wireless Issues Community Group Listserv 
mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>>
Date: Tuesday, July 21, 2020 at 13:15
To: 
WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU<mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU> 
mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>>
Subject: Re: [WIRELESS-LAN] MAC Randomization, a step further...
Tim had mentioned the following: “On iOS 14, the MAC is set per ESSID and is 
changed once every 24 hours.”

Chris then mentioned that he found one iOS 14 device that, as long as it 
remains connected, the MAC remains the same, even beyond 24hrs.

Has anyone else done testing? Please share your results.

Hector Rios, Wireless Network Architect
The University of Texas at Austin



From: The EDUCAUSE Wireless Issues Community Group Listserv 
mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>> 
On Behalf Of Johnson, Christopher
Sent: Monday, July 20, 2020 10:19 AM
To: 
WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU<mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>
Subject: Re: [WIRELESS-LAN] MAC Randomization, a step further...

Default behavior matters indeed. Got a preview of what to expect over the 
weekend.

Found one individual that was in Aruba Airwave “12 Times” for their iPhone 14.0 
over past couple of weeks and another “6 times”. It appears that as long as the 
device remains “connected” to the network beyond the 24 hours, the MAC Address 
will remain the same. Although if they’re fully de-authenticated or move say 
into an elevator or outside (or a class phone reboot occurs in the pocket) – 
then the MAC Address will update upon establishing a new connection – that is 
just the initial observation I saw.
Christopher Johnson
Wireless Network Engineer
Office of Technology Solutions | Illinois State University
(309) 438-8444

Stay connected with ISU IT news and tips with @ISU IT Help on 
Facebook<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.facebook.com%2FISUITHelp%2F=02%7C01%7Ctim.cappalli%40MICROSOFT.COM%7C812e787d6bf44c983a5508d82dc389f8%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637309665991169119=PXsoY8%2BEIC%2BPM7k%2BUGHb%2FMTJDqGDXwk4poUYtk9r8%2B8%3D=0>
 and 
Twitter<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftwitter.com%2FISUITHelp=02%7C01%7Ctim.cappalli%40MICROSOFT.COM%7C812e787d6bf44c983a5508d82dc389f8%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637309665991179105=2pCDlSeZJHJ6MzyQJ9e2DrMbVba6%2FFaV4M%2B%2FOJ16BfU%3D=0>
From: The EDUCAUSE Wireless Issues Community Group Listserv 
mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>> 
On Behalf Of Enfield, Chuck
Sent: Tuesday, July 14, 2020 12:36 PM
To: 
WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU<mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>
Subject: Re: [WIRELESS-LAN] MAC Randomization, a step further...

[This message came from

Re: [WIRELESS-LAN] MAC Randomization, a step further...

[Norman Elton]

This is all fascinating, I’m looking forward to getting my hands on a
public beta.

Those “in the know” ... does this impact 1x networks as well as open? It
seems that if you’re connecting with credentials, there’s already a trust
relationship in place.

And is the feature enabled for networks that were configured before
upgrading to iOS 14?

Fun times,

Norman Elton



On Tue, Jul 21, 2020 at 2:55 PM Rios, Hector J <
hector.r...@austin.utexas.edu> wrote:

> I just finished reading the “Apple Beta Software Program Agreement”.
> Interesting information:
>
>
>
> “Don’t blog, post screen shots, tweet, or publicly post information about
> the public beta software, and don’t discuss the public beta software with
> or demonstrate it to others who are not in the Apple Beta Software Program.”
>
>
>
> So, I need everyone to sign up to the beta software program so we can
> continue this conversation (J/K)
>
>
>
> Hector Rios, Wireless Network Architect
>
> The University of Texas at Austin
>
>
>
>
>
>
>
> *From:* The EDUCAUSE Wireless Issues Community Group Listserv <
> WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU> *On Behalf Of *Tim Cappalli
> *Sent:* Tuesday, July 21, 2020 1:06 PM
> *To:* WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
> *Subject:* Re: [WIRELESS-LAN] MAC Randomization, a step further...
>
>
>
>  Yeah, good catch Chris! I’d be interested in seeing some field data as
> well. The only info I saw was that it changed every 24 hours, but it sounds
> like there’s a * which indicates inactivity / not associated.
>
>
>
> It makes much more sense that it wouldn’t change if the device maintains
> an active connection as there are really no privacy concerns until the
> device disconnects and moves.
>
>
>
> tim
>
>
>
> *From: *The EDUCAUSE Wireless Issues Community Group Listserv <
> WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>
> *Date: *Tuesday, July 21, 2020 at 13:15
> *To: *WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU <
> WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>
> *Subject: *Re: [WIRELESS-LAN] MAC Randomization, a step further...
>
> Tim had mentioned the following: “On iOS 14, the MAC is set per ESSID and
> is changed once every 24 hours.”
>
>
>
> Chris then mentioned that he found one iOS 14 device that, as long as it
> remains connected, the MAC remains the same, even beyond 24hrs.
>
>
>
> Has anyone else done testing? Please share your results.
>
>
>
> Hector Rios, Wireless Network Architect
>
> The University of Texas at Austin
>
>
>
>
>
>
>
> *From:* The EDUCAUSE Wireless Issues Community Group Listserv <
> WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU> *On Behalf Of *Johnson, Christopher
> *Sent:* Monday, July 20, 2020 10:19 AM
> *To:* WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
> *Subject:* Re: [WIRELESS-LAN] MAC Randomization, a step further...
>
>
>
> Default behavior matters indeed. Got a preview of what to expect over the
> weekend.
>
>
>
> Found one individual that was in Aruba Airwave “12 Times” for their iPhone
> 14.0 over past couple of weeks and another “6 times”. It appears that as
> long as the device remains “connected” to the network beyond the 24 hours,
> the MAC Address will remain the same. Although if they’re fully
> de-authenticated or move say into an elevator or outside (or a class phone
> reboot occurs in the pocket) – then the MAC Address will update upon
> establishing a new connection – that is just the initial observation I saw.
>
> *Christopher Johnson*
> Wireless Network Engineer
> Office of Technology Solutions | Illinois State University
> (309) 438-8444
>
> Stay connected with ISU IT news and tips with @ISU IT Help on Facebook
> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.facebook.com%2FISUITHelp%2F=02%7C01%7Ctim.cappalli%40MICROSOFT.COM%7Cc141f9922e2241c5153b08d82d99b43e%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637309485473827397=FGJLeAaYuQi53K0C3dSVpVbg7exX195P4eSHJJGLjUU%3D=0>
> and Twitter
> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftwitter.com%2FISUITHelp=02%7C01%7Ctim.cappalli%40MICROSOFT.COM%7Cc141f9922e2241c5153b08d82d99b43e%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637309485473837398=bC3HH3eN2hDSeTLdAbF9%2Fwgs286voXLDLZXX1VuSlxk%3D=0>
>
> *From:* The EDUCAUSE Wireless Issues Community Group Listserv <
> WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU> *On Behalf Of *Enfield, Chuck
> *Sent:* Tuesday, July 14, 2020 12:36 PM
> *To:* WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
> *Subject:* Re: [WIRELESS-LAN] MAC Randomization, a step further...
>
>
>
> *[This message came from an external source. If suspicious, report to
> ab...@ilstu.edu ] *
>
> True, but default behavior matters

RE: [WIRELESS-LAN] MAC Randomization, a step further...

[Rios, Hector J]

I just finished reading the “Apple Beta Software Program Agreement”. 
Interesting information:

“Don’t blog, post screen shots, tweet, or publicly post information about the 
public beta software, and don’t discuss the public beta software with or 
demonstrate it to others who are not in the Apple Beta Software Program.”

So, I need everyone to sign up to the beta software program so we can continue 
this conversation (J/K)

Hector Rios, Wireless Network Architect
The University of Texas at Austin



From: The EDUCAUSE Wireless Issues Community Group Listserv 
 On Behalf Of Tim Cappalli
Sent: Tuesday, July 21, 2020 1:06 PM
To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
Subject: Re: [WIRELESS-LAN] MAC Randomization, a step further...

 Yeah, good catch Chris! I’d be interested in seeing some field data as well. 
The only info I saw was that it changed every 24 hours, but it sounds like 
there’s a * which indicates inactivity / not associated.

It makes much more sense that it wouldn’t change if the device maintains an 
active connection as there are really no privacy concerns until the device 
disconnects and moves.

tim

From: The EDUCAUSE Wireless Issues Community Group Listserv 
mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>>
Date: Tuesday, July 21, 2020 at 13:15
To: 
WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU<mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU> 
mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>>
Subject: Re: [WIRELESS-LAN] MAC Randomization, a step further...
Tim had mentioned the following: “On iOS 14, the MAC is set per ESSID and is 
changed once every 24 hours.”

Chris then mentioned that he found one iOS 14 device that, as long as it 
remains connected, the MAC remains the same, even beyond 24hrs.

Has anyone else done testing? Please share your results.

Hector Rios, Wireless Network Architect
The University of Texas at Austin



From: The EDUCAUSE Wireless Issues Community Group Listserv 
mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>> 
On Behalf Of Johnson, Christopher
Sent: Monday, July 20, 2020 10:19 AM
To: 
WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU<mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>
Subject: Re: [WIRELESS-LAN] MAC Randomization, a step further...

Default behavior matters indeed. Got a preview of what to expect over the 
weekend.

Found one individual that was in Aruba Airwave “12 Times” for their iPhone 14.0 
over past couple of weeks and another “6 times”. It appears that as long as the 
device remains “connected” to the network beyond the 24 hours, the MAC Address 
will remain the same. Although if they’re fully de-authenticated or move say 
into an elevator or outside (or a class phone reboot occurs in the pocket) – 
then the MAC Address will update upon establishing a new connection – that is 
just the initial observation I saw.
Christopher Johnson
Wireless Network Engineer
Office of Technology Solutions | Illinois State University
(309) 438-8444

Stay connected with ISU IT news and tips with @ISU IT Help on 
Facebook<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.facebook.com%2FISUITHelp%2F=02%7C01%7Ctim.cappalli%40MICROSOFT.COM%7Cc141f9922e2241c5153b08d82d99b43e%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637309485473827397=FGJLeAaYuQi53K0C3dSVpVbg7exX195P4eSHJJGLjUU%3D=0>
 and 
Twitter<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftwitter.com%2FISUITHelp=02%7C01%7Ctim.cappalli%40MICROSOFT.COM%7Cc141f9922e2241c5153b08d82d99b43e%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637309485473837398=bC3HH3eN2hDSeTLdAbF9%2Fwgs286voXLDLZXX1VuSlxk%3D=0>
From: The EDUCAUSE Wireless Issues Community Group Listserv 
mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>> 
On Behalf Of Enfield, Chuck
Sent: Tuesday, July 14, 2020 12:36 PM
To: 
WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU<mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>
Subject: Re: [WIRELESS-LAN] MAC Randomization, a step further...

[This message came from an external source. If suspicious, report to 
ab...@ilstu.edu<mailto:ab...@ilstu.edu>]
True, but default behavior matters.

From: The EDUCAUSE Wireless Issues Community Group Listserv 
mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>> 
On Behalf Of Rios, Hector J
Sent: Tuesday, July 14, 2020 1:12 PM
To: 
WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU<mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>
Subject: Re: [WIRELESS-LAN] MAC Randomization, a step further...

Please note that MAC randomization is not just a feature of Android and iOS. It 
is supported across other operating systems.

Hector Rios, Wireless Network Architect
The University of Texas at Austin



From: The EDUCAUSE Wireless Issues Community Group Listserv 
mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>> 
On Behalf Of Jonathan Miller
Sent: Tuesday, July 14, 2020 11:32 AM
To: 
WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU<mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>
Subject: Re: [WIRELESS-LAN] MAC Randomization, a step further...

For those of us using ClearPass to authenticate 

Re: [WIRELESS-LAN] MAC Randomization, a step further...

[Tim Cappalli]

 Yeah, good catch Chris! I’d be interested in seeing some field data as well. 
The only info I saw was that it changed every 24 hours, but it sounds like 
there’s a * which indicates inactivity / not associated.

It makes much more sense that it wouldn’t change if the device maintains an 
active connection as there are really no privacy concerns until the device 
disconnects and moves.

tim

From: The EDUCAUSE Wireless Issues Community Group Listserv 

Date: Tuesday, July 21, 2020 at 13:15
To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU 
Subject: Re: [WIRELESS-LAN] MAC Randomization, a step further...
Tim had mentioned the following: “On iOS 14, the MAC is set per ESSID and is 
changed once every 24 hours.”

Chris then mentioned that he found one iOS 14 device that, as long as it 
remains connected, the MAC remains the same, even beyond 24hrs.

Has anyone else done testing? Please share your results.

Hector Rios, Wireless Network Architect
The University of Texas at Austin



From: The EDUCAUSE Wireless Issues Community Group Listserv 
 On Behalf Of Johnson, Christopher
Sent: Monday, July 20, 2020 10:19 AM
To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
Subject: Re: [WIRELESS-LAN] MAC Randomization, a step further...

Default behavior matters indeed. Got a preview of what to expect over the 
weekend.

Found one individual that was in Aruba Airwave “12 Times” for their iPhone 14.0 
over past couple of weeks and another “6 times”. It appears that as long as the 
device remains “connected” to the network beyond the 24 hours, the MAC Address 
will remain the same. Although if they’re fully de-authenticated or move say 
into an elevator or outside (or a class phone reboot occurs in the pocket) – 
then the MAC Address will update upon establishing a new connection – that is 
just the initial observation I saw.
Christopher Johnson
Wireless Network Engineer
Office of Technology Solutions | Illinois State University
(309) 438-8444

Stay connected with ISU IT news and tips with @ISU IT Help on 
Facebook<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.facebook.com%2FISUITHelp%2F=02%7C01%7Ctim.cappalli%40MICROSOFT.COM%7Cc141f9922e2241c5153b08d82d99b43e%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637309485473827397=FGJLeAaYuQi53K0C3dSVpVbg7exX195P4eSHJJGLjUU%3D=0>
 and 
Twitter<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftwitter.com%2FISUITHelp=02%7C01%7Ctim.cappalli%40MICROSOFT.COM%7Cc141f9922e2241c5153b08d82d99b43e%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637309485473837398=bC3HH3eN2hDSeTLdAbF9%2Fwgs286voXLDLZXX1VuSlxk%3D=0>
From: The EDUCAUSE Wireless Issues Community Group Listserv 
mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>> 
On Behalf Of Enfield, Chuck
Sent: Tuesday, July 14, 2020 12:36 PM
To: 
WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU<mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>
Subject: Re: [WIRELESS-LAN] MAC Randomization, a step further...

[This message came from an external source. If suspicious, report to 
ab...@ilstu.edu<mailto:ab...@ilstu.edu>]
True, but default behavior matters.

From: The EDUCAUSE Wireless Issues Community Group Listserv 
mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>> 
On Behalf Of Rios, Hector J
Sent: Tuesday, July 14, 2020 1:12 PM
To: 
WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU<mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>
Subject: Re: [WIRELESS-LAN] MAC Randomization, a step further...

Please note that MAC randomization is not just a feature of Android and iOS. It 
is supported across other operating systems.

Hector Rios, Wireless Network Architect
The University of Texas at Austin



From: The EDUCAUSE Wireless Issues Community Group Listserv 
mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>> 
On Behalf Of Jonathan Miller
Sent: Tuesday, July 14, 2020 11:32 AM
To: 
WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU<mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>
Subject: Re: [WIRELESS-LAN] MAC Randomization, a step further...

For those of us using ClearPass to authenticate users to eduroam, does this 
mean that every iOS device will get registered as a new endpoint every day?  
For others, does your NAC store a client's MAC persistently?  I'm assuming that 
the answer to both is yes.

How can we plan for the impact of that on our databases?  Should we delete all 
iOS and Android devices after 48 hours?  Am I missing something obvious?

Jonathan Miller
Senior Network Analyst
Franklin and Marshall College


On Fri, Jul 10, 2020 at 4:37 PM Enfield, Chuck 
mailto:cae...@psu.edu>> wrote:
PS – My plan for supporting our guest network will be to tell any user who 
contacts us with an Apple device that the network is fine and they should 
contact Apple for device support.  I can’t get away with that for our 
enterprise network, but Apple is going to own the guest problem.

From: The EDUCAUSE Wireless Issues Community Group Listserv 
mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>> 
On Behalf Of Enfield, Chuck
Sent: Friday, July 10, 2020 4

RE: [WIRELESS-LAN] MAC Randomization, a step further...

[Rios, Hector J]

Tim had mentioned the following: “On iOS 14, the MAC is set per ESSID and is 
changed once every 24 hours.”

Chris then mentioned that he found one iOS 14 device that, as long as it 
remains connected, the MAC remains the same, even beyond 24hrs.

Has anyone else done testing? Please share your results.

Hector Rios, Wireless Network Architect
The University of Texas at Austin



From: The EDUCAUSE Wireless Issues Community Group Listserv 
 On Behalf Of Johnson, Christopher
Sent: Monday, July 20, 2020 10:19 AM
To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
Subject: Re: [WIRELESS-LAN] MAC Randomization, a step further...

Default behavior matters indeed. Got a preview of what to expect over the 
weekend.

Found one individual that was in Aruba Airwave “12 Times” for their iPhone 14.0 
over past couple of weeks and another “6 times”. It appears that as long as the 
device remains “connected” to the network beyond the 24 hours, the MAC Address 
will remain the same. Although if they’re fully de-authenticated or move say 
into an elevator or outside (or a class phone reboot occurs in the pocket) – 
then the MAC Address will update upon establishing a new connection – that is 
just the initial observation I saw.
Christopher Johnson
Wireless Network Engineer
Office of Technology Solutions | Illinois State University
(309) 438-8444

Stay connected with ISU IT news and tips with @ISU IT Help on 
Facebook<https://www.facebook.com/ISUITHelp/> and 
Twitter<https://twitter.com/ISUITHelp>
From: The EDUCAUSE Wireless Issues Community Group Listserv 
mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>> 
On Behalf Of Enfield, Chuck
Sent: Tuesday, July 14, 2020 12:36 PM
To: 
WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU<mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>
Subject: Re: [WIRELESS-LAN] MAC Randomization, a step further...

[This message came from an external source. If suspicious, report to 
ab...@ilstu.edu<mailto:ab...@ilstu.edu>]
True, but default behavior matters.

From: The EDUCAUSE Wireless Issues Community Group Listserv 
mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>> 
On Behalf Of Rios, Hector J
Sent: Tuesday, July 14, 2020 1:12 PM
To: 
WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU<mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>
Subject: Re: [WIRELESS-LAN] MAC Randomization, a step further...

Please note that MAC randomization is not just a feature of Android and iOS. It 
is supported across other operating systems.

Hector Rios, Wireless Network Architect
The University of Texas at Austin



From: The EDUCAUSE Wireless Issues Community Group Listserv 
mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>> 
On Behalf Of Jonathan Miller
Sent: Tuesday, July 14, 2020 11:32 AM
To: 
WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU<mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>
Subject: Re: [WIRELESS-LAN] MAC Randomization, a step further...

For those of us using ClearPass to authenticate users to eduroam, does this 
mean that every iOS device will get registered as a new endpoint every day?  
For others, does your NAC store a client's MAC persistently?  I'm assuming that 
the answer to both is yes.

How can we plan for the impact of that on our databases?  Should we delete all 
iOS and Android devices after 48 hours?  Am I missing something obvious?

Jonathan Miller
Senior Network Analyst
Franklin and Marshall College


On Fri, Jul 10, 2020 at 4:37 PM Enfield, Chuck 
mailto:cae...@psu.edu>> wrote:
PS – My plan for supporting our guest network will be to tell any user who 
contacts us with an Apple device that the network is fine and they should 
contact Apple for device support.  I can’t get away with that for our 
enterprise network, but Apple is going to own the guest problem.

From: The EDUCAUSE Wireless Issues Community Group Listserv 
mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>> 
On Behalf Of Enfield, Chuck
Sent: Friday, July 10, 2020 4:34 PM
To: 
WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU<mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>
Subject: Re: [WIRELESS-LAN] MAC Randomization, a step further...

My point wasn’t to debate Passpoint either.  I’m wondering if Apple actually 
has a plan, and if so, if they’ve bothered to tell anybody.

From: The EDUCAUSE Wireless Issues Community Group Listserv 
mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>> 
On Behalf Of Tim Cappalli
Sent: Friday, July 10, 2020 4:22 PM
To: 
WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU<mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>
Subject: Re: [WIRELESS-LAN] MAC Randomization, a step further...

Passpoint is not just about mobile network operators. Any identity provider can 
provision a Passpoint profile. That is the whole drive behind OpenRoaming. The 
industry goal is that every user has at least 2 Passpoint profiles on their 
devices: one tied to their enterprise/school identity and the other tied to a 
personal identity. The traditional enterprise/school onboarding process stays 
largely the same, except some additional Passpoint logic is added.

Mo

Re: [WIRELESS-LAN] MAC Randomization, a step further...

[Tim Cappalli]

EAP-TTLS is simply an EAP method. What credential and subject type you use is 
up to your configuration and policy.

RE: EMMs (speaking generically), yes many need to have additional config 
options exposed for Passpoint parameters but you don't need client certificates 
for Passpoint. If no customers ask for a capability, it likely will not be 
implemented in any product. It won't be an overnight flip of the switch to 
eliminate your existing 802.1X SSID so those EMM managed devices can continue 
as they normally would. Visitors with credentials from another IdP can 
seamlessly connect in the meantime. It's a marathon, not a sprint.

Unfortunately there's been so much negativity around Passpoint over the years 
that not many people have engaged with vendors on it. Just my opinion. Outside 
of the eduroam advisory council and historical interest in the technology, I 
really have no other vested interest in the topic.

Tim

From: The EDUCAUSE Wireless Issues Community Group Listserv 
 on behalf of James Andrewartha 

Sent: Monday, July 20, 2020, 23:11
To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
Subject: Re: [WIRELESS-LAN] MAC Randomization, a step further...

On 21/7/20 11:04 am, Tim Cappalli wrote:
> Both major Wi-Fi vendors have Passpoint offerings that are either
> available or in preview.

I'm talking about the client side. Intune doesn't even have a CA either
(no the short-lived one for conditional access doesn't count). Where's
the Microsoft supported agent that does device-specific TTLS-PAP like
you suggest?

Also 
https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.securew2.com%2Fblog%2Fpitfalls-of-eap-ttls-pap%2Fdata=02%7C01%7Ctim.cappalli%40MICROSOFT.COM%7Ca83f24666b4f421d719408d82d23afd8%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637308978591817681sdata=AsFb0%2BDplHGzVWHxo6qWKqw9XYJuH5Md3YhdYEpQFzY%3Dreserved=0
 is the top
google result for [TTLS-PAP], admittedly it's about user credentials not
device credentials but it's still a risk.

--
James Andrewartha
Network & Projects Engineer
Christ Church Grammar School
Claremont, Western Australia
Ph. (08) 9442 1757
Mob. 0424 160 877

**
Replies to EDUCAUSE Community Group emails are sent to the entire community 
list. If you want to reply only to the person who sent the message, copy and 
paste their email address and forward the email reply. Additional participation 
and subscription information can be found at 
https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.educause.edu%2Fcommunitydata=02%7C01%7Ctim.cappalli%40MICROSOFT.COM%7Ca83f24666b4f421d719408d82d23afd8%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637308978591817681sdata=SMZUP69xXENTzXPmKbytbI%2FMYBuP3Hwk4jsSDy9D1rA%3Dreserved=0


**
Replies to EDUCAUSE Community Group emails are sent to the entire community 
list. If you want to reply only to the person who sent the message, copy and 
paste their email address and forward the email reply. Additional participation 
and subscription information can be found at https://www.educause.edu/community

Re: [WIRELESS-LAN] MAC Randomization, a step further...

[James Andrewartha]

On 21/7/20 11:04 am, Tim Cappalli wrote:
> Both major Wi-Fi vendors have Passpoint offerings that are either
> available or in preview.

I'm talking about the client side. Intune doesn't even have a CA either
(no the short-lived one for conditional access doesn't count). Where's
the Microsoft supported agent that does device-specific TTLS-PAP like
you suggest?

Also https://www.securew2.com/blog/pitfalls-of-eap-ttls-pap/ is the top
google result for [TTLS-PAP], admittedly it's about user credentials not
device credentials but it's still a risk.

-- 
James Andrewartha
Network & Projects Engineer
Christ Church Grammar School
Claremont, Western Australia
Ph. (08) 9442 1757
Mob. 0424 160 877

**
Replies to EDUCAUSE Community Group emails are sent to the entire community 
list. If you want to reply only to the person who sent the message, copy and 
paste their email address and forward the email reply. Additional participation 
and subscription information can be found at https://www.educause.edu/community

Re: [WIRELESS-LAN] MAC Randomization, a step further...

[Tim Cappalli]

Both major Wi-Fi vendors have Passpoint offerings that are either available or 
in preview.

Tim

From: The EDUCAUSE Wireless Issues Community Group Listserv 

Date: Monday, July 20, 2020 at 22:34
To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU 
Subject: Re: [WIRELESS-LAN] MAC Randomization, a step further...
On 21/7/20 5:21 am, Tim Cappalli wrote:
> Passpoint solves all of these issues.

Where is the vendor support for it? Autopilot white glove doesn't even
support wireless networks at all.

--
James Andrewartha
Network & Projects Engineer
Christ Church Grammar School
Claremont, Western Australia
Ph. (08) 9442 1757
Mob. 0424 160 877

**
Replies to EDUCAUSE Community Group emails are sent to the entire community 
list. If you want to reply only to the person who sent the message, copy and 
paste their email address and forward the email reply. Additional participation 
and subscription information can be found at 
https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.educause.edu%2Fcommunitydata=02%7C01%7Ctim.cappalli%40MICROSOFT.COM%7C3cb035d18c7248779cf308d82d1ea118%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637308956870326069sdata=8LcqGwSOQ31E0JZYw3WMIcq2zVYQ9fYbb%2Bj7zl1RzGY%3Dreserved=0

**
Replies to EDUCAUSE Community Group emails are sent to the entire community 
list. If you want to reply only to the person who sent the message, copy and 
paste their email address and forward the email reply. Additional participation 
and subscription information can be found at https://www.educause.edu/community

Re: [WIRELESS-LAN] MAC Randomization, a step further...

[James Andrewartha]

On 21/7/20 5:21 am, Tim Cappalli wrote:
> Passpoint solves all of these issues.

Where is the vendor support for it? Autopilot white glove doesn't even
support wireless networks at all.

-- 
James Andrewartha
Network & Projects Engineer
Christ Church Grammar School
Claremont, Western Australia
Ph. (08) 9442 1757
Mob. 0424 160 877

**
Replies to EDUCAUSE Community Group emails are sent to the entire community 
list. If you want to reply only to the person who sent the message, copy and 
paste their email address and forward the email reply. Additional participation 
and subscription information can be found at https://www.educause.edu/community

RE: [WIRELESS-LAN] MAC Randomization, a step further...

[Johnson, Christopher]

Jonathan, I was thinking the same thing about possibility of multiple macs onto 
a single unique certificate for Airwave.

I am curious though. Does anyone happen to know the maximum number of 
"unique/randomized mac addresses" that can be allotted?

Christopher Johnson
Wireless Network Engineer
Office of Technology Solutions | Illinois State University
(309) 438-8444

Stay connected with ISU IT news and tips with @ISU IT Help on Facebook and 
Twitter

-Original Message-
From: The EDUCAUSE Wireless Issues Community Group Listserv 
 On Behalf Of Jonathan Waldrep
Sent: Monday, July 20, 2020 12:46 PM
To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
Subject: Re: [WIRELESS-LAN] MAC Randomization, a step further...

[This message came from an external source. If suspicious, report to 
ab...@ilstu.edu<mailto:ab...@ilstu.edu>]

For .1x connections, per device certs seems to be the way to go. I'm not sure 
if Airwave and other monitoring tools have a way to consolidate multiple macs 
to a single device based on the cert, though.

For guests, I've been tossing around the idea of an open network. No .1x, no 
PSK, no captive portal. Affiliates would be encouraged to use eduroam via SSO 
nag. Columbia University had a presentation on how they are doing the open 
network side of this. I suspect the most difficult part will be getting legal 
on board. Who has an open network? What have your experiences been? This is 
only tangentially related, so feel free to split it into a new thread.

On 2020-07-20 15:18:46, Johnson, Christopher wrote:
> Default behavior matters indeed. Got a preview of what to expect over the 
> weekend.
>
> Found one individual that was in Aruba Airwave “12 Times” for their iPhone 
> 14.0 over past couple of weeks and another “6 times”. It appears that as long 
> as the device remains “connected” to the network beyond the 24 hours, the MAC 
> Address will remain the same. Although if they’re fully de-authenticated or 
> move say into an elevator or outside (or a class phone reboot occurs in the 
> pocket) – then the MAC Address will update upon establishing a new connection 
> – that is just the initial observation I saw.
> Christopher Johnson
> Wireless Network Engineer
> Office of Technology Solutions | Illinois State University
> (309) 438-8444
>
> Stay connected with ISU IT news and tips with @ISU IT Help on 
> Facebook<https://www.facebook.com/ISUITHelp/> and 
> Twitter<https://twitter.com/ISUITHelp>
> From: The EDUCAUSE Wireless Issues Community Group Listserv 
>  On Behalf Of Enfield, Chuck
> Sent: Tuesday, July 14, 2020 12:36 PM
> To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
> Subject: Re: [WIRELESS-LAN] MAC Randomization, a step further...
>
> [This message came from an external source. If suspicious, report to 
> ab...@ilstu.edu<mailto:ab...@ilstu.edu>]
> True, but default behavior matters.
>
> From: The EDUCAUSE Wireless Issues Community Group Listserv 
> mailto:WIRELESS-LAN@LISTSERV.EDUCA
> USE.EDU>> On Behalf Of Rios, Hector J
> Sent: Tuesday, July 14, 2020 1:12 PM
> To: 
> WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU<mailto:WIRELESS-LAN@LISTSERV.EDUCAU
> SE.EDU>
> Subject: Re: [WIRELESS-LAN] MAC Randomization, a step further...
>
> Please note that MAC randomization is not just a feature of Android and iOS. 
> It is supported across other operating systems.
>
> Hector Rios, Wireless Network Architect The University of Texas at 
> Austin
>
>
>
> From: The EDUCAUSE Wireless Issues Community Group Listserv 
> mailto:WIRELESS-LAN@LISTSERV.EDUCA
> USE.EDU>> On Behalf Of Jonathan Miller
> Sent: Tuesday, July 14, 2020 11:32 AM
> To: 
> WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU<mailto:WIRELESS-LAN@LISTSERV.EDUCAU
> SE.EDU>
> Subject: Re: [WIRELESS-LAN] MAC Randomization, a step further...
>
> For those of us using ClearPass to authenticate users to eduroam, does this 
> mean that every iOS device will get registered as a new endpoint every day?  
> For others, does your NAC store a client's MAC persistently?  I'm assuming 
> that the answer to both is yes.
>
> How can we plan for the impact of that on our databases?  Should we delete 
> all iOS and Android devices after 48 hours?  Am I missing something obvious?
>
> Jonathan Miller
> Senior Network Analyst
> Franklin and Marshall College
>
>
> On Fri, Jul 10, 2020 at 4:37 PM Enfield, Chuck 
> mailto:cae...@psu.edu>> wrote:
> PS – My plan for supporting our guest network will be to tell any user who 
> contacts us with an Apple device that the network is fine and they should 
> contact Apple for device support.  I can’t get away with that for our 
> enterprise network, but Apple is going to own the guest problem.
>
> From: The EDUCAUSE Wireless Issues Community Group Listserv 
&g

Re: [WIRELESS-LAN] MAC Randomization, a step further...

[Jonathan Waldrep]

For .1x connections, per device certs seems to be the way to go. I'm not
sure if Airwave and other monitoring tools have a way to consolidate
multiple macs to a single device based on the cert, though.

For guests, I've been tossing around the idea of an open network. No
.1x, no PSK, no captive portal. Affiliates would be encouraged to use
eduroam via SSO nag. Columbia University had a presentation on how they
are doing the open network side of this. I suspect the most difficult
part will be getting legal on board. Who has an open network? What have
your experiences been? This is only tangentially related, so feel free
to split it into a new thread.

On 2020-07-20 15:18:46, Johnson, Christopher wrote:
> Default behavior matters indeed. Got a preview of what to expect over the 
> weekend.
> 
> Found one individual that was in Aruba Airwave “12 Times” for their iPhone 
> 14.0 over past couple of weeks and another “6 times”. It appears that as long 
> as the device remains “connected” to the network beyond the 24 hours, the MAC 
> Address will remain the same. Although if they’re fully de-authenticated or 
> move say into an elevator or outside (or a class phone reboot occurs in the 
> pocket) – then the MAC Address will update upon establishing a new connection 
> – that is just the initial observation I saw.
> Christopher Johnson
> Wireless Network Engineer
> Office of Technology Solutions | Illinois State University
> (309) 438-8444
> 
> Stay connected with ISU IT news and tips with @ISU IT Help on 
> Facebook<https://www.facebook.com/ISUITHelp/> and 
> Twitter<https://twitter.com/ISUITHelp>
> From: The EDUCAUSE Wireless Issues Community Group Listserv 
>  On Behalf Of Enfield, Chuck
> Sent: Tuesday, July 14, 2020 12:36 PM
> To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
> Subject: Re: [WIRELESS-LAN] MAC Randomization, a step further...
> 
> [This message came from an external source. If suspicious, report to 
> ab...@ilstu.edu<mailto:ab...@ilstu.edu>]
> True, but default behavior matters.
> 
> From: The EDUCAUSE Wireless Issues Community Group Listserv 
> mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>>
>  On Behalf Of Rios, Hector J
> Sent: Tuesday, July 14, 2020 1:12 PM
> To: 
> WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU<mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>
> Subject: Re: [WIRELESS-LAN] MAC Randomization, a step further...
> 
> Please note that MAC randomization is not just a feature of Android and iOS. 
> It is supported across other operating systems.
> 
> Hector Rios, Wireless Network Architect
> The University of Texas at Austin
> 
> 
> 
> From: The EDUCAUSE Wireless Issues Community Group Listserv 
> mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>>
>  On Behalf Of Jonathan Miller
> Sent: Tuesday, July 14, 2020 11:32 AM
> To: 
> WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU<mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>
> Subject: Re: [WIRELESS-LAN] MAC Randomization, a step further...
> 
> For those of us using ClearPass to authenticate users to eduroam, does this 
> mean that every iOS device will get registered as a new endpoint every day?  
> For others, does your NAC store a client's MAC persistently?  I'm assuming 
> that the answer to both is yes.
> 
> How can we plan for the impact of that on our databases?  Should we delete 
> all iOS and Android devices after 48 hours?  Am I missing something obvious?
> 
> Jonathan Miller
> Senior Network Analyst
> Franklin and Marshall College
> 
> 
> On Fri, Jul 10, 2020 at 4:37 PM Enfield, Chuck 
> mailto:cae...@psu.edu>> wrote:
> PS – My plan for supporting our guest network will be to tell any user who 
> contacts us with an Apple device that the network is fine and they should 
> contact Apple for device support.  I can’t get away with that for our 
> enterprise network, but Apple is going to own the guest problem.
> 
> From: The EDUCAUSE Wireless Issues Community Group Listserv 
> mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>>
>  On Behalf Of Enfield, Chuck
> Sent: Friday, July 10, 2020 4:34 PM
> To: 
> WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU<mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>
> Subject: Re: [WIRELESS-LAN] MAC Randomization, a step further...
> 
> My point wasn’t to debate Passpoint either.  I’m wondering if Apple actually 
> has a plan, and if so, if they’ve bothered to tell anybody.
> 
> From: The EDUCAUSE Wireless Issues Community Group Listserv 
> mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>>
>  On Behalf Of Tim Cappalli
> Sent: Friday, July 10, 2020 4:22 PM
> To: 
> WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU<mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>
> Subject: Re: [WIRELESS-LAN] MAC Randomization, a step further...
> 
> Passpoint is not just 

RE: [WIRELESS-LAN] MAC Randomization, a step further...

[Johnson, Christopher]

Default behavior matters indeed. Got a preview of what to expect over the 
weekend.

Found one individual that was in Aruba Airwave “12 Times” for their iPhone 14.0 
over past couple of weeks and another “6 times”. It appears that as long as the 
device remains “connected” to the network beyond the 24 hours, the MAC Address 
will remain the same. Although if they’re fully de-authenticated or move say 
into an elevator or outside (or a class phone reboot occurs in the pocket) – 
then the MAC Address will update upon establishing a new connection – that is 
just the initial observation I saw.
Christopher Johnson
Wireless Network Engineer
Office of Technology Solutions | Illinois State University
(309) 438-8444

Stay connected with ISU IT news and tips with @ISU IT Help on 
Facebook<https://www.facebook.com/ISUITHelp/> and 
Twitter<https://twitter.com/ISUITHelp>
From: The EDUCAUSE Wireless Issues Community Group Listserv 
 On Behalf Of Enfield, Chuck
Sent: Tuesday, July 14, 2020 12:36 PM
To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
Subject: Re: [WIRELESS-LAN] MAC Randomization, a step further...

[This message came from an external source. If suspicious, report to 
ab...@ilstu.edu<mailto:ab...@ilstu.edu>]
True, but default behavior matters.

From: The EDUCAUSE Wireless Issues Community Group Listserv 
mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>> 
On Behalf Of Rios, Hector J
Sent: Tuesday, July 14, 2020 1:12 PM
To: 
WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU<mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>
Subject: Re: [WIRELESS-LAN] MAC Randomization, a step further...

Please note that MAC randomization is not just a feature of Android and iOS. It 
is supported across other operating systems.

Hector Rios, Wireless Network Architect
The University of Texas at Austin



From: The EDUCAUSE Wireless Issues Community Group Listserv 
mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>> 
On Behalf Of Jonathan Miller
Sent: Tuesday, July 14, 2020 11:32 AM
To: 
WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU<mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>
Subject: Re: [WIRELESS-LAN] MAC Randomization, a step further...

For those of us using ClearPass to authenticate users to eduroam, does this 
mean that every iOS device will get registered as a new endpoint every day?  
For others, does your NAC store a client's MAC persistently?  I'm assuming that 
the answer to both is yes.

How can we plan for the impact of that on our databases?  Should we delete all 
iOS and Android devices after 48 hours?  Am I missing something obvious?

Jonathan Miller
Senior Network Analyst
Franklin and Marshall College


On Fri, Jul 10, 2020 at 4:37 PM Enfield, Chuck 
mailto:cae...@psu.edu>> wrote:
PS – My plan for supporting our guest network will be to tell any user who 
contacts us with an Apple device that the network is fine and they should 
contact Apple for device support.  I can’t get away with that for our 
enterprise network, but Apple is going to own the guest problem.

From: The EDUCAUSE Wireless Issues Community Group Listserv 
mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>> 
On Behalf Of Enfield, Chuck
Sent: Friday, July 10, 2020 4:34 PM
To: 
WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU<mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>
Subject: Re: [WIRELESS-LAN] MAC Randomization, a step further...

My point wasn’t to debate Passpoint either.  I’m wondering if Apple actually 
has a plan, and if so, if they’ve bothered to tell anybody.

From: The EDUCAUSE Wireless Issues Community Group Listserv 
mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>> 
On Behalf Of Tim Cappalli
Sent: Friday, July 10, 2020 4:22 PM
To: 
WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU<mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>
Subject: Re: [WIRELESS-LAN] MAC Randomization, a step further...

Passpoint is not just about mobile network operators. Any identity provider can 
provision a Passpoint profile. That is the whole drive behind OpenRoaming. The 
industry goal is that every user has at least 2 Passpoint profiles on their 
devices: one tied to their enterprise/school identity and the other tied to a 
personal identity. The traditional enterprise/school onboarding process stays 
largely the same, except some additional Passpoint logic is added.

Mobile network operators / cell providers are only one (optional) piece of the 
puzzle.

Probably should start a separate thread for anything deeper on Passpoint beyond 
it being a solution for network access. Don’t want to take away from the OG 
conversation.

tim

From: The EDUCAUSE Wireless Issues Community Group Listserv 
mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>>
Date: Friday, July 10, 2020 at 16:17
To: 
WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU<mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU> 
mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>>
Subject: Re: [WIRELESS-LAN] MAC Randomization, a step further...
Understood, but few Wi-Fi operators actually support Passpoint on their 
networks.  Since Apple is elimina

RE: [WIRELESS-LAN] MAC Randomization, a step further...

[Enfield, Chuck]

True, but default behavior matters.

From: The EDUCAUSE Wireless Issues Community Group Listserv 
 On Behalf Of Rios, Hector J
Sent: Tuesday, July 14, 2020 1:12 PM
To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
Subject: Re: [WIRELESS-LAN] MAC Randomization, a step further...

Please note that MAC randomization is not just a feature of Android and iOS. It 
is supported across other operating systems.

Hector Rios, Wireless Network Architect
The University of Texas at Austin



From: The EDUCAUSE Wireless Issues Community Group Listserv 
 On Behalf Of Jonathan Miller
Sent: Tuesday, July 14, 2020 11:32 AM
To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
Subject: Re: [WIRELESS-LAN] MAC Randomization, a step further...

For those of us using ClearPass to authenticate users to eduroam, does this 
mean that every iOS device will get registered as a new endpoint every day?  
For others, does your NAC store a client's MAC persistently?  I'm assuming that 
the answer to both is yes.

How can we plan for the impact of that on our databases?  Should we delete all 
iOS and Android devices after 48 hours?  Am I missing something obvious?

Jonathan Miller
Senior Network Analyst
Franklin and Marshall College


On Fri, Jul 10, 2020 at 4:37 PM Enfield, Chuck 
mailto:cae...@psu.edu>> wrote:
PS – My plan for supporting our guest network will be to tell any user who 
contacts us with an Apple device that the network is fine and they should 
contact Apple for device support.  I can’t get away with that for our 
enterprise network, but Apple is going to own the guest problem.

From: The EDUCAUSE Wireless Issues Community Group Listserv 
mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>> 
On Behalf Of Enfield, Chuck
Sent: Friday, July 10, 2020 4:34 PM
To: 
WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU<mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>
Subject: Re: [WIRELESS-LAN] MAC Randomization, a step further...

My point wasn’t to debate Passpoint either.  I’m wondering if Apple actually 
has a plan, and if so, if they’ve bothered to tell anybody.

From: The EDUCAUSE Wireless Issues Community Group Listserv 
mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>> 
On Behalf Of Tim Cappalli
Sent: Friday, July 10, 2020 4:22 PM
To: 
WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU<mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>
Subject: Re: [WIRELESS-LAN] MAC Randomization, a step further...

Passpoint is not just about mobile network operators. Any identity provider can 
provision a Passpoint profile. That is the whole drive behind OpenRoaming. The 
industry goal is that every user has at least 2 Passpoint profiles on their 
devices: one tied to their enterprise/school identity and the other tied to a 
personal identity. The traditional enterprise/school onboarding process stays 
largely the same, except some additional Passpoint logic is added.

Mobile network operators / cell providers are only one (optional) piece of the 
puzzle.

Probably should start a separate thread for anything deeper on Passpoint beyond 
it being a solution for network access. Don’t want to take away from the OG 
conversation.

tim

From: The EDUCAUSE Wireless Issues Community Group Listserv 
mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>>
Date: Friday, July 10, 2020 at 16:17
To: 
WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU<mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU> 
mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>>
Subject: Re: [WIRELESS-LAN] MAC Randomization, a step further...
Understood, but few Wi-Fi operators actually support Passpoint on their 
networks.  Since Apple is eliminating the alternatives, they either must be 
idiots (my bet) or have a proposal for what we should all being doing instead.

I still get really confused looks when I try to discuss Passpoint with my 
contacts at the major cellular providers, so it can’t possibly be a realistic 
option for most of us.

From: The EDUCAUSE Wireless Issues Community Group Listserv 
mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>> 
On Behalf Of Tim Cappalli
Sent: Friday, July 10, 2020 4:07 PM
To: 
WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU<mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>
Subject: Re: [WIRELESS-LAN] MAC Randomization, a step further...

Not sure I follow. Passpoint is an industry-wide solution for secure Wi-Fi 
roaming. Passpoint has been supported on iOS and macOS (along with Windows and 
Android) for a number of years.

I definitely don’t follow this comment: “you can’t onboard your Apple to enable 
identity-based auth.”

tim


From: The EDUCAUSE Wireless Issues Community Group Listserv 
mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>>
Date: Friday, July 10, 2020 at 16:04
To: 
WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU<mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU> 
mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>>
Subject: Re: [WIRELESS-LAN] MAC Randomization, a step further...
So you can’t use an Apple MAC address for guest auth, and you can’t onboard 
your Apple to enable identity-based auth.  Apple must be thinking that they ca

RE: [WIRELESS-LAN] MAC Randomization, a step further...

[Rios, Hector J]

Please note that MAC randomization is not just a feature of Android and iOS. It 
is supported across other operating systems.

Hector Rios, Wireless Network Architect
The University of Texas at Austin



From: The EDUCAUSE Wireless Issues Community Group Listserv 
 On Behalf Of Jonathan Miller
Sent: Tuesday, July 14, 2020 11:32 AM
To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
Subject: Re: [WIRELESS-LAN] MAC Randomization, a step further...

For those of us using ClearPass to authenticate users to eduroam, does this 
mean that every iOS device will get registered as a new endpoint every day?  
For others, does your NAC store a client's MAC persistently?  I'm assuming that 
the answer to both is yes.

How can we plan for the impact of that on our databases?  Should we delete all 
iOS and Android devices after 48 hours?  Am I missing something obvious?

Jonathan Miller
Senior Network Analyst
Franklin and Marshall College


On Fri, Jul 10, 2020 at 4:37 PM Enfield, Chuck 
mailto:cae...@psu.edu>> wrote:
PS – My plan for supporting our guest network will be to tell any user who 
contacts us with an Apple device that the network is fine and they should 
contact Apple for device support.  I can’t get away with that for our 
enterprise network, but Apple is going to own the guest problem.

From: The EDUCAUSE Wireless Issues Community Group Listserv 
mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>> 
On Behalf Of Enfield, Chuck
Sent: Friday, July 10, 2020 4:34 PM
To: 
WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU<mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>
Subject: Re: [WIRELESS-LAN] MAC Randomization, a step further...

My point wasn’t to debate Passpoint either.  I’m wondering if Apple actually 
has a plan, and if so, if they’ve bothered to tell anybody.

From: The EDUCAUSE Wireless Issues Community Group Listserv 
mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>> 
On Behalf Of Tim Cappalli
Sent: Friday, July 10, 2020 4:22 PM
To: 
WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU<mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>
Subject: Re: [WIRELESS-LAN] MAC Randomization, a step further...

Passpoint is not just about mobile network operators. Any identity provider can 
provision a Passpoint profile. That is the whole drive behind OpenRoaming. The 
industry goal is that every user has at least 2 Passpoint profiles on their 
devices: one tied to their enterprise/school identity and the other tied to a 
personal identity. The traditional enterprise/school onboarding process stays 
largely the same, except some additional Passpoint logic is added.

Mobile network operators / cell providers are only one (optional) piece of the 
puzzle.

Probably should start a separate thread for anything deeper on Passpoint beyond 
it being a solution for network access. Don’t want to take away from the OG 
conversation.

tim

From: The EDUCAUSE Wireless Issues Community Group Listserv 
mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>>
Date: Friday, July 10, 2020 at 16:17
To: 
WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU<mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU> 
mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>>
Subject: Re: [WIRELESS-LAN] MAC Randomization, a step further...
Understood, but few Wi-Fi operators actually support Passpoint on their 
networks.  Since Apple is eliminating the alternatives, they either must be 
idiots (my bet) or have a proposal for what we should all being doing instead.

I still get really confused looks when I try to discuss Passpoint with my 
contacts at the major cellular providers, so it can’t possibly be a realistic 
option for most of us.

From: The EDUCAUSE Wireless Issues Community Group Listserv 
mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>> 
On Behalf Of Tim Cappalli
Sent: Friday, July 10, 2020 4:07 PM
To: 
WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU<mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>
Subject: Re: [WIRELESS-LAN] MAC Randomization, a step further...

Not sure I follow. Passpoint is an industry-wide solution for secure Wi-Fi 
roaming. Passpoint has been supported on iOS and macOS (along with Windows and 
Android) for a number of years.

I definitely don’t follow this comment: “you can’t onboard your Apple to enable 
identity-based auth.”

tim


From: The EDUCAUSE Wireless Issues Community Group Listserv 
mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>>
Date: Friday, July 10, 2020 at 16:04
To: 
WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU<mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU> 
mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>>
Subject: Re: [WIRELESS-LAN] MAC Randomization, a step further...
So you can’t use an Apple MAC address for guest auth, and you can’t onboard 
your Apple to enable identity-based auth.  Apple must be thinking that they can 
drag the entire world, kicking and screaming, into federated authentication 
that Apple products ship knowing how to do (Passpoint, openroaming, etc.).  Do 
they have a proposal for this that I missed?

From: The EDUCAUSE Wireless Issues Community Group Listserv 

Re: [WIRELESS-LAN] MAC Randomization, a step further...

[Tim Cappalli]

There’s an endpoint cleanup interval configuration in cluster-wide parameters, 
although I’d recommend reaching out to someone at Aruba (or your NAC provider 
to ask how they recommend dealing with some of these new changes).

tim

From: The EDUCAUSE Wireless Issues Community Group Listserv 

Date: Tuesday, July 14, 2020 at 12:31
To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU 
Subject: Re: [WIRELESS-LAN] MAC Randomization, a step further...
For those of us using ClearPass to authenticate users to eduroam, does this 
mean that every iOS device will get registered as a new endpoint every day?  
For others, does your NAC store a client's MAC persistently?  I'm assuming that 
the answer to both is yes.

How can we plan for the impact of that on our databases?  Should we delete all 
iOS and Android devices after 48 hours?  Am I missing something obvious?

Jonathan Miller
Senior Network Analyst
Franklin and Marshall College


On Fri, Jul 10, 2020 at 4:37 PM Enfield, Chuck 
mailto:cae...@psu.edu>> wrote:
PS – My plan for supporting our guest network will be to tell any user who 
contacts us with an Apple device that the network is fine and they should 
contact Apple for device support.  I can’t get away with that for our 
enterprise network, but Apple is going to own the guest problem.

From: The EDUCAUSE Wireless Issues Community Group Listserv 
mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>> 
On Behalf Of Enfield, Chuck
Sent: Friday, July 10, 2020 4:34 PM
To: 
WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU<mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>
Subject: Re: [WIRELESS-LAN] MAC Randomization, a step further...

My point wasn’t to debate Passpoint either.  I’m wondering if Apple actually 
has a plan, and if so, if they’ve bothered to tell anybody.

From: The EDUCAUSE Wireless Issues Community Group Listserv 
mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>> 
On Behalf Of Tim Cappalli
Sent: Friday, July 10, 2020 4:22 PM
To: 
WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU<mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>
Subject: Re: [WIRELESS-LAN] MAC Randomization, a step further...

Passpoint is not just about mobile network operators. Any identity provider can 
provision a Passpoint profile. That is the whole drive behind OpenRoaming. The 
industry goal is that every user has at least 2 Passpoint profiles on their 
devices: one tied to their enterprise/school identity and the other tied to a 
personal identity. The traditional enterprise/school onboarding process stays 
largely the same, except some additional Passpoint logic is added.

Mobile network operators / cell providers are only one (optional) piece of the 
puzzle.

Probably should start a separate thread for anything deeper on Passpoint beyond 
it being a solution for network access. Don’t want to take away from the OG 
conversation.

tim

From: The EDUCAUSE Wireless Issues Community Group Listserv 
mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>>
Date: Friday, July 10, 2020 at 16:17
To: 
WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU<mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU> 
mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>>
Subject: Re: [WIRELESS-LAN] MAC Randomization, a step further...
Understood, but few Wi-Fi operators actually support Passpoint on their 
networks.  Since Apple is eliminating the alternatives, they either must be 
idiots (my bet) or have a proposal for what we should all being doing instead.

I still get really confused looks when I try to discuss Passpoint with my 
contacts at the major cellular providers, so it can’t possibly be a realistic 
option for most of us.

From: The EDUCAUSE Wireless Issues Community Group Listserv 
mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>> 
On Behalf Of Tim Cappalli
Sent: Friday, July 10, 2020 4:07 PM
To: 
WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU<mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>
Subject: Re: [WIRELESS-LAN] MAC Randomization, a step further...

Not sure I follow. Passpoint is an industry-wide solution for secure Wi-Fi 
roaming. Passpoint has been supported on iOS and macOS (along with Windows and 
Android) for a number of years.

I definitely don’t follow this comment: “you can’t onboard your Apple to enable 
identity-based auth.”

tim


From: The EDUCAUSE Wireless Issues Community Group Listserv 
mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>>
Date: Friday, July 10, 2020 at 16:04
To: 
WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU<mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU> 
mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>>
Subject: Re: [WIRELESS-LAN] MAC Randomization, a step further...
So you can’t use an Apple MAC address for guest auth, and you can’t onboard 
your Apple to enable identity-based auth.  Apple must be thinking that they can 
drag the entire world, kicking and screaming, into federated authentication 
that Apple products ship knowing how to do (Passpoint, openroaming, etc.).  Do 
they have a proposal for this that I missed?

From: The EDUCAUSE Wireless Issues Community Group Listserv 

Re: [WIRELESS-LAN] MAC Randomization, a step further...

[Jonathan Miller]

For those of us using ClearPass to authenticate users to eduroam, does this
mean that every iOS device will get registered as a new endpoint every
day?  For others, does your NAC store a client's MAC persistently?  I'm
assuming that the answer to both is yes.

How can we plan for the impact of that on our databases?  Should we delete
all iOS and Android devices after 48 hours?  Am I missing something obvious?

Jonathan Miller
Senior Network Analyst
Franklin and Marshall College


On Fri, Jul 10, 2020 at 4:37 PM Enfield, Chuck  wrote:

> PS – My plan for supporting our guest network will be to tell any user who
> contacts us with an Apple device that the network is fine and they should
> contact Apple for device support.  I can’t get away with that for our
> enterprise network, but Apple is going to own the guest problem.
>
>
>
> *From:* The EDUCAUSE Wireless Issues Community Group Listserv <
> WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU> *On Behalf Of *Enfield, Chuck
> *Sent:* Friday, July 10, 2020 4:34 PM
> *To:* WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
> *Subject:* Re: [WIRELESS-LAN] MAC Randomization, a step further...
>
>
>
> My point wasn’t to debate Passpoint either.  I’m wondering if Apple
> actually has a plan, and if so, if they’ve bothered to tell anybody.
>
>
>
> *From:* The EDUCAUSE Wireless Issues Community Group Listserv <
> WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU> *On Behalf Of *Tim Cappalli
> *Sent:* Friday, July 10, 2020 4:22 PM
> *To:* WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
> *Subject:* Re: [WIRELESS-LAN] MAC Randomization, a step further...
>
>
>
> Passpoint is not just about mobile network operators. Any identity
> provider can provision a Passpoint profile. That is the whole drive behind
> OpenRoaming. The industry goal is that every user has at least 2 Passpoint
> profiles on their devices: one tied to their enterprise/school identity and
> the other tied to a personal identity. The traditional enterprise/school
> onboarding process stays largely the same, except some additional Passpoint
> logic is added.
>
>
>
> Mobile network operators / cell providers are only one (optional) piece of
> the puzzle.
>
>
>
> Probably should start a separate thread for anything deeper on Passpoint
> beyond it being a solution for network access. Don’t want to take away from
> the OG conversation.
>
>
>
> tim
>
>
>
> *From: *The EDUCAUSE Wireless Issues Community Group Listserv <
> WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>
> *Date: *Friday, July 10, 2020 at 16:17
> *To: *WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU <
> WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>
> *Subject: *Re: [WIRELESS-LAN] MAC Randomization, a step further...
>
> Understood, but few Wi-Fi operators actually support Passpoint on their
> networks.  Since Apple is eliminating the alternatives, they either must be
> idiots (my bet) or have a proposal for what we should all being doing
> instead.
>
>
>
> I still get really confused looks when I try to discuss Passpoint with my
> contacts at the major cellular providers, so it can’t possibly be a
> realistic option for most of us.
>
>
>
> *From:* The EDUCAUSE Wireless Issues Community Group Listserv <
> WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU> *On Behalf Of *Tim Cappalli
> *Sent:* Friday, July 10, 2020 4:07 PM
> *To:* WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
> *Subject:* Re: [WIRELESS-LAN] MAC Randomization, a step further...
>
>
>
> Not sure I follow. Passpoint is an industry-wide solution for secure Wi-Fi
> roaming. Passpoint has been supported on iOS and macOS (along with Windows
> and Android) for a number of years.
>
>
>
> I definitely don’t follow this comment: “you can’t onboard your Apple to
> enable identity-based auth.”
>
>
>
> tim
>
>
>
>
>
> *From: *The EDUCAUSE Wireless Issues Community Group Listserv <
> WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>
> *Date: *Friday, July 10, 2020 at 16:04
> *To: *WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU <
> WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>
> *Subject: *Re: [WIRELESS-LAN] MAC Randomization, a step further...
>
> So you can’t use an Apple MAC address for guest auth, and you can’t
> onboard your Apple to enable identity-based auth.  Apple must be thinking
> that they can drag the entire world, kicking and screaming, into federated
> authentication that Apple products ship knowing how to do (Passpoint,
> openroaming, etc.).  Do they have a proposal for this that I missed?
>
>
>
> *From:* The EDUCAUSE Wireless Issues Community Group Listserv <
> WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU> *On Behalf Of *Rios, Hector J
> *Sent:* Friday, July 10, 2020 2:56 PM
> *To:* WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
> *Subject:* [WIRELESS-LAN

RE: [WIRELESS-LAN] MAC Randomization, a step further...

[Enfield, Chuck]

Ahh.  I glossed right over the 24-hour part.  That’s much less distressing, but 
I’m going to have a beer anyway.

Thanks Tim.

From: The EDUCAUSE Wireless Issues Community Group Listserv 
 On Behalf Of Tim Cappalli
Sent: Friday, July 10, 2020 5:04 PM
To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
Subject: Re: [WIRELESS-LAN] MAC Randomization, a step further...

But why would that change anything? A user on campus for a football game is 
there for less than 24 hours. The MAC address changes per ESSID, every 24 
hours. I don’t understand what changes here for that use case?

It really only impacts mid to long term guests. So I guess in your example, 
parents weekend may be the one that is affected. But even then, dropping the 
lease times would solve the problem. I believe many wireless vendors recommend 
a visitor lease time of 1-8 hours.

From: The EDUCAUSE Wireless Issues Community Group Listserv 
mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>>
Date: Friday, July 10, 2020 at 17:01
To: 
WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU<mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU> 
mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>>
Subject: Re: [WIRELESS-LAN] MAC Randomization, a step further...
Tim,
With Covid, any lease time would not be an issue. But how big were your home 
football events / tailgate parties / parent weekends at Brandeis? I’m focusing 
more on the impact of those events on the guest side of things.
Brad

From: The EDUCAUSE Wireless Issues Community Group Listserv 
[mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU] On Behalf Of Tim Cappalli
Sent: Friday, July 10, 2020 3:53 PM
To: 
WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU<mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>
Subject: [EXTERNAL]Re: [WIRELESS-LAN] MAC Randomization, a step further...

Agreed on IPv6, but even for IPv4, I imagine most folks are running short 
leases on a visitor network, so I don’t really think much changes here. If your 
leases are 12 hours or less, there should be no impact.

tim

From: The EDUCAUSE Wireless Issues Community Group Listserv 
mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>>
Date: Friday, July 10, 2020 at 16:51
To: 
WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU<mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU> 
mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>>
Subject: Re: [WIRELESS-LAN] MAC Randomization, a step further...
Maybe a good use case for IPv6

From: The EDUCAUSE Wireless Issues Community Group Listserv 
[mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU] On Behalf Of Enfield, Chuck
Sent: Friday, July 10, 2020 3:49 PM
To: 
WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU<mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>
Subject: [EXTERNAL]Re: [WIRELESS-LAN] MAC Randomization, a step further...

Uhg.  Didn’t even think about that.

From: The EDUCAUSE Wireless Issues Community Group Listserv 
mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>> 
On Behalf Of Eric LaCroix
Sent: Friday, July 10, 2020 4:48 PM
To: 
WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU<mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>
Subject: Re: [WIRELESS-LAN] MAC Randomization, a step further...

We’re all going to need to check the TTL on DHCP leases… some of our scopes 
will get eaten alive otherwise.

From: The EDUCAUSE Wireless Issues Community Group Listserv 
mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>> 
on behalf of "Floyd, Brad" mailto:bfl...@mail.smu.edu>>
Reply-To: The EDUCAUSE Wireless Issues Community Group Listserv 
mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>>
Date: Friday, July 10, 2020 at 3:42 PM
To: 
"WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU<mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>" 
mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>>
Subject: Re: [WIRELESS-LAN] MAC Randomization, a step further...

Thanks Tim. I just started a conversation with my SE.
Brad

From: The EDUCAUSE Wireless Issues Community Group Listserv 
[mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU] On Behalf Of Tim Cappalli
Sent: Friday, July 10, 2020 2:07 PM
To: 
WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU<mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>
Subject: [EXTERNAL]Re: [WIRELESS-LAN] MAC Randomization, a step further...

For extended visitor use cases (over 1 day), Passpoint is really the only 
feasible solution moving forward. Aruba has a Passpoint offering/service called 
Air Pass and WBA’s OpenRoaming initiative is gaining a lot of support.

tim

From: The EDUCAUSE Wireless Issues Community Group Listserv 
mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>>
Date: Friday, July 10, 2020 at 15:04
To: 
WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU<mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU> 
mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>>
Subject: Re: [WIRELESS-LAN] MAC Randomization, a step further...
Tim,
Anything in the works from Aruba about how best to deal with ClearPass Guest 
MAC Auth?
Thanks,
Brad

From: The EDUCAUSE Wireless Issues Community Group Listserv 
[mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU] On Behalf Of Tim Cappalli
Sent: Friday, July 10, 2020 2:01 PM
To: 

Re: [WIRELESS-LAN] MAC Randomization, a step further...

[Tim Cappalli]

But why would that change anything? A user on campus for a football game is 
there for less than 24 hours. The MAC address changes per ESSID, every 24 
hours. I don’t understand what changes here for that use case?

It really only impacts mid to long term guests. So I guess in your example, 
parents weekend may be the one that is affected. But even then, dropping the 
lease times would solve the problem. I believe many wireless vendors recommend 
a visitor lease time of 1-8 hours.

From: The EDUCAUSE Wireless Issues Community Group Listserv 

Date: Friday, July 10, 2020 at 17:01
To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU 
Subject: Re: [WIRELESS-LAN] MAC Randomization, a step further...
Tim,
With Covid, any lease time would not be an issue. But how big were your home 
football events / tailgate parties / parent weekends at Brandeis? I’m focusing 
more on the impact of those events on the guest side of things.
Brad

From: The EDUCAUSE Wireless Issues Community Group Listserv 
[mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU] On Behalf Of Tim Cappalli
Sent: Friday, July 10, 2020 3:53 PM
To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
Subject: [EXTERNAL]Re: [WIRELESS-LAN] MAC Randomization, a step further...

Agreed on IPv6, but even for IPv4, I imagine most folks are running short 
leases on a visitor network, so I don’t really think much changes here. If your 
leases are 12 hours or less, there should be no impact.

tim

From: The EDUCAUSE Wireless Issues Community Group Listserv 
mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>>
Date: Friday, July 10, 2020 at 16:51
To: 
WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU<mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU> 
mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>>
Subject: Re: [WIRELESS-LAN] MAC Randomization, a step further...
Maybe a good use case for IPv6

From: The EDUCAUSE Wireless Issues Community Group Listserv 
[mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU] On Behalf Of Enfield, Chuck
Sent: Friday, July 10, 2020 3:49 PM
To: 
WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU<mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>
Subject: [EXTERNAL]Re: [WIRELESS-LAN] MAC Randomization, a step further...

Uhg.  Didn’t even think about that.

From: The EDUCAUSE Wireless Issues Community Group Listserv 
mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>> 
On Behalf Of Eric LaCroix
Sent: Friday, July 10, 2020 4:48 PM
To: 
WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU<mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>
Subject: Re: [WIRELESS-LAN] MAC Randomization, a step further...

We’re all going to need to check the TTL on DHCP leases… some of our scopes 
will get eaten alive otherwise.

From: The EDUCAUSE Wireless Issues Community Group Listserv 
mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>> 
on behalf of "Floyd, Brad" mailto:bfl...@mail.smu.edu>>
Reply-To: The EDUCAUSE Wireless Issues Community Group Listserv 
mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>>
Date: Friday, July 10, 2020 at 3:42 PM
To: 
"WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU<mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>" 
mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>>
Subject: Re: [WIRELESS-LAN] MAC Randomization, a step further...

Thanks Tim. I just started a conversation with my SE.
Brad

From: The EDUCAUSE Wireless Issues Community Group Listserv 
[mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU] On Behalf Of Tim Cappalli
Sent: Friday, July 10, 2020 2:07 PM
To: 
WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU<mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>
Subject: [EXTERNAL]Re: [WIRELESS-LAN] MAC Randomization, a step further...

For extended visitor use cases (over 1 day), Passpoint is really the only 
feasible solution moving forward. Aruba has a Passpoint offering/service called 
Air Pass and WBA’s OpenRoaming initiative is gaining a lot of support.

tim

From: The EDUCAUSE Wireless Issues Community Group Listserv 
mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>>
Date: Friday, July 10, 2020 at 15:04
To: 
WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU<mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU> 
mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>>
Subject: Re: [WIRELESS-LAN] MAC Randomization, a step further...
Tim,
Anything in the works from Aruba about how best to deal with ClearPass Guest 
MAC Auth?
Thanks,
Brad

From: The EDUCAUSE Wireless Issues Community Group Listserv 
[mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU] On Behalf Of Tim Cappalli
Sent: Friday, July 10, 2020 2:01 PM
To: 
WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU<mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>
Subject: [EXTERNAL]Re: [WIRELESS-LAN] MAC Randomization, a step further...

Connected MAC randomization on iOS will be enabled by default, just like on 
Android (starting in 10).

Two major differences:

  1.  iOS does not expose the randomization knob (to disable it) to end users 
during initial connection. It is available after connection in the saved 
network list
  2.  On Android (version 10 and 11), the MAC is set once per ESSID for the 
lifetime of the OS 

RE: [WIRELESS-LAN] MAC Randomization, a step further...

[Floyd, Brad]

Tim,
With Covid, any lease time would not be an issue. But how big were your home 
football events / tailgate parties / parent weekends at Brandeis? I'm focusing 
more on the impact of those events on the guest side of things.
Brad

From: The EDUCAUSE Wireless Issues Community Group Listserv 
[mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU] On Behalf Of Tim Cappalli
Sent: Friday, July 10, 2020 3:53 PM
To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
Subject: [EXTERNAL]Re: [WIRELESS-LAN] MAC Randomization, a step further...

Agreed on IPv6, but even for IPv4, I imagine most folks are running short 
leases on a visitor network, so I don't really think much changes here. If your 
leases are 12 hours or less, there should be no impact.

tim

From: The EDUCAUSE Wireless Issues Community Group Listserv 
mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>>
Date: Friday, July 10, 2020 at 16:51
To: 
WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU<mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU> 
mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>>
Subject: Re: [WIRELESS-LAN] MAC Randomization, a step further...
Maybe a good use case for IPv6

From: The EDUCAUSE Wireless Issues Community Group Listserv 
[mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU] On Behalf Of Enfield, Chuck
Sent: Friday, July 10, 2020 3:49 PM
To: 
WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU<mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>
Subject: [EXTERNAL]Re: [WIRELESS-LAN] MAC Randomization, a step further...

Uhg.  Didn't even think about that.

From: The EDUCAUSE Wireless Issues Community Group Listserv 
mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>> 
On Behalf Of Eric LaCroix
Sent: Friday, July 10, 2020 4:48 PM
To: 
WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU<mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>
Subject: Re: [WIRELESS-LAN] MAC Randomization, a step further...

We're all going to need to check the TTL on DHCP leases... some of our scopes 
will get eaten alive otherwise.

From: The EDUCAUSE Wireless Issues Community Group Listserv 
mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>> 
on behalf of "Floyd, Brad" mailto:bfl...@mail.smu.edu>>
Reply-To: The EDUCAUSE Wireless Issues Community Group Listserv 
mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>>
Date: Friday, July 10, 2020 at 3:42 PM
To: 
"WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU<mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>" 
mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>>
Subject: Re: [WIRELESS-LAN] MAC Randomization, a step further...

Thanks Tim. I just started a conversation with my SE.
Brad

From: The EDUCAUSE Wireless Issues Community Group Listserv 
[mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU] On Behalf Of Tim Cappalli
Sent: Friday, July 10, 2020 2:07 PM
To: 
WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU<mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>
Subject: [EXTERNAL]Re: [WIRELESS-LAN] MAC Randomization, a step further...

For extended visitor use cases (over 1 day), Passpoint is really the only 
feasible solution moving forward. Aruba has a Passpoint offering/service called 
Air Pass and WBA's OpenRoaming initiative is gaining a lot of support.

tim

From: The EDUCAUSE Wireless Issues Community Group Listserv 
mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>>
Date: Friday, July 10, 2020 at 15:04
To: 
WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU<mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU> 
mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>>
Subject: Re: [WIRELESS-LAN] MAC Randomization, a step further...
Tim,
Anything in the works from Aruba about how best to deal with ClearPass Guest 
MAC Auth?
Thanks,
Brad

From: The EDUCAUSE Wireless Issues Community Group Listserv 
[mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU] On Behalf Of Tim Cappalli
Sent: Friday, July 10, 2020 2:01 PM
To: 
WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU<mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>
Subject: [EXTERNAL]Re: [WIRELESS-LAN] MAC Randomization, a step further...

Connected MAC randomization on iOS will be enabled by default, just like on 
Android (starting in 10).

Two major differences:
1)  iOS does not expose the randomization knob (to disable it) to end users 
during initial connection. It is available after connection in the saved 
network list
2)  On Android (version 10 and 11), the MAC is set once per ESSID for the 
lifetime of the OS instance (aka until a factory reset). On iOS 14, the MAC is 
set per ESSID and is changed once every 24 hours.

Note that Android 11 has a developer option to enable a per-connection MAC 
which likely indicates this will enabled by default or exposed to users in 
Android 12.

tim

From: The EDUCAUSE Wireless Issues Community Group Listserv 
mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>>
Date: Friday, July 10, 2020 at 14:57
To: 
WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU<mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU> 
mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>>
Subject: [WIRELESS-LAN] MAC Randomization, a step further...
Apple is moving forward with their privacy efforts. The next step i

Re: [WIRELESS-LAN] MAC Randomization, a step further...

[Eric LaCroix]

A quick internet search seems to indicate the default for a Windows DHCP server 
is 8 days. On a visitor network, likely it’s a much shorter time, and may even 
be handled by something other than a Windows server (perhaps the onboarding 
device handles it). But once students come onto a production network because 
they’re trusted/802.1x etc., it’s possible that some of us use Windows and left 
the defaults and didn’t consider it would become an issue since that population 
really doesn’t change often. … Now I’m curious to know what our defaults are. 
But not TOO curious – it’s Friday at 5pm.

Have a good weekend everyone!
Eric
--
Eric LaCroix P’20 P’22, Director of Technology
New Hampton School<https://www.newhampton.org/> • 603-677-3454
Where a fulfilled life begins.


From: The EDUCAUSE Wireless Issues Community Group Listserv 
 on behalf of Tim Cappalli 
<0194c9ecac40-dmarc-requ...@listserv.educause.edu>
Reply-To: The EDUCAUSE Wireless Issues Community Group Listserv 

Date: Friday, July 10, 2020 at 4:52 PM
To: "WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU" 
Subject: Re: [WIRELESS-LAN] MAC Randomization, a step further...

Agreed on IPv6, but even for IPv4, I imagine most folks are running short 
leases on a visitor network, so I don’t really think much changes here. If your 
leases are 12 hours or less, there should be no impact.

tim

From: The EDUCAUSE Wireless Issues Community Group Listserv 

Date: Friday, July 10, 2020 at 16:51
To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU 
Subject: Re: [WIRELESS-LAN] MAC Randomization, a step further...
Maybe a good use case for IPv6

From: The EDUCAUSE Wireless Issues Community Group Listserv 
[mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU] On Behalf Of Enfield, Chuck
Sent: Friday, July 10, 2020 3:49 PM
To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
Subject: [EXTERNAL]Re: [WIRELESS-LAN] MAC Randomization, a step further...

Uhg.  Didn’t even think about that.

From: The EDUCAUSE Wireless Issues Community Group Listserv 
mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>> 
On Behalf Of Eric LaCroix
Sent: Friday, July 10, 2020 4:48 PM
To: 
WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU<mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>
Subject: Re: [WIRELESS-LAN] MAC Randomization, a step further...

We’re all going to need to check the TTL on DHCP leases… some of our scopes 
will get eaten alive otherwise.

From: The EDUCAUSE Wireless Issues Community Group Listserv 
mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>> 
on behalf of "Floyd, Brad" mailto:bfl...@mail.smu.edu>>
Reply-To: The EDUCAUSE Wireless Issues Community Group Listserv 
mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>>
Date: Friday, July 10, 2020 at 3:42 PM
To: 
"WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU<mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>" 
mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>>
Subject: Re: [WIRELESS-LAN] MAC Randomization, a step further...

Thanks Tim. I just started a conversation with my SE.
Brad

From: The EDUCAUSE Wireless Issues Community Group Listserv 
[mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU] On Behalf Of Tim Cappalli
Sent: Friday, July 10, 2020 2:07 PM
To: 
WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU<mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>
Subject: [EXTERNAL]Re: [WIRELESS-LAN] MAC Randomization, a step further...

For extended visitor use cases (over 1 day), Passpoint is really the only 
feasible solution moving forward. Aruba has a Passpoint offering/service called 
Air Pass and WBA’s OpenRoaming initiative is gaining a lot of support.

tim

From: The EDUCAUSE Wireless Issues Community Group Listserv 
mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>>
Date: Friday, July 10, 2020 at 15:04
To: 
WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU<mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU> 
mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>>
Subject: Re: [WIRELESS-LAN] MAC Randomization, a step further...
Tim,
Anything in the works from Aruba about how best to deal with ClearPass Guest 
MAC Auth?
Thanks,
Brad

From: The EDUCAUSE Wireless Issues Community Group Listserv 
[mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU] On Behalf Of Tim Cappalli
Sent: Friday, July 10, 2020 2:01 PM
To: 
WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU<mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>
Subject: [EXTERNAL]Re: [WIRELESS-LAN] MAC Randomization, a step further...

Connected MAC randomization on iOS will be enabled by default, just like on 
Android (starting in 10).

Two major differences:

  1.  iOS does not expose the randomization knob (to disable it) to end users 
during initial connection. It is available after connection in the saved 
network list
  2.  On Android (version 10 and 11), the MAC is set once per ESSID for the 
lifetime of the OS instance (aka until a factory reset). On iOS 14, the MAC is 
set per ESSID and is changed once every 24 hours.

Note that Android 11 has a developer option to enable a per-connection MAC 
which likely indicates this will enabled by default or expos

Re: [WIRELESS-LAN] MAC Randomization, a step further...

[Tim Cappalli]

Agreed on IPv6, but even for IPv4, I imagine most folks are running short 
leases on a visitor network, so I don’t really think much changes here. If your 
leases are 12 hours or less, there should be no impact.

tim

From: The EDUCAUSE Wireless Issues Community Group Listserv 

Date: Friday, July 10, 2020 at 16:51
To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU 
Subject: Re: [WIRELESS-LAN] MAC Randomization, a step further...
Maybe a good use case for IPv6

From: The EDUCAUSE Wireless Issues Community Group Listserv 
[mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU] On Behalf Of Enfield, Chuck
Sent: Friday, July 10, 2020 3:49 PM
To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
Subject: [EXTERNAL]Re: [WIRELESS-LAN] MAC Randomization, a step further...

Uhg.  Didn’t even think about that.

From: The EDUCAUSE Wireless Issues Community Group Listserv 
mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>> 
On Behalf Of Eric LaCroix
Sent: Friday, July 10, 2020 4:48 PM
To: 
WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU<mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>
Subject: Re: [WIRELESS-LAN] MAC Randomization, a step further...

We’re all going to need to check the TTL on DHCP leases… some of our scopes 
will get eaten alive otherwise.

From: The EDUCAUSE Wireless Issues Community Group Listserv 
mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>> 
on behalf of "Floyd, Brad" mailto:bfl...@mail.smu.edu>>
Reply-To: The EDUCAUSE Wireless Issues Community Group Listserv 
mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>>
Date: Friday, July 10, 2020 at 3:42 PM
To: 
"WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU<mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>" 
mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>>
Subject: Re: [WIRELESS-LAN] MAC Randomization, a step further...

Thanks Tim. I just started a conversation with my SE.
Brad

From: The EDUCAUSE Wireless Issues Community Group Listserv 
[mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU] On Behalf Of Tim Cappalli
Sent: Friday, July 10, 2020 2:07 PM
To: 
WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU<mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>
Subject: [EXTERNAL]Re: [WIRELESS-LAN] MAC Randomization, a step further...

For extended visitor use cases (over 1 day), Passpoint is really the only 
feasible solution moving forward. Aruba has a Passpoint offering/service called 
Air Pass and WBA’s OpenRoaming initiative is gaining a lot of support.

tim

From: The EDUCAUSE Wireless Issues Community Group Listserv 
mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>>
Date: Friday, July 10, 2020 at 15:04
To: 
WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU<mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU> 
mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>>
Subject: Re: [WIRELESS-LAN] MAC Randomization, a step further...
Tim,
Anything in the works from Aruba about how best to deal with ClearPass Guest 
MAC Auth?
Thanks,
Brad

From: The EDUCAUSE Wireless Issues Community Group Listserv 
[mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU] On Behalf Of Tim Cappalli
Sent: Friday, July 10, 2020 2:01 PM
To: 
WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU<mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>
Subject: [EXTERNAL]Re: [WIRELESS-LAN] MAC Randomization, a step further...

Connected MAC randomization on iOS will be enabled by default, just like on 
Android (starting in 10).

Two major differences:

  1.  iOS does not expose the randomization knob (to disable it) to end users 
during initial connection. It is available after connection in the saved 
network list
  2.  On Android (version 10 and 11), the MAC is set once per ESSID for the 
lifetime of the OS instance (aka until a factory reset). On iOS 14, the MAC is 
set per ESSID and is changed once every 24 hours.

Note that Android 11 has a developer option to enable a per-connection MAC 
which likely indicates this will enabled by default or exposed to users in 
Android 12.

tim

From: The EDUCAUSE Wireless Issues Community Group Listserv 
mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>>
Date: Friday, July 10, 2020 at 14:57
To: 
WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU<mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU> 
mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>>
Subject: [WIRELESS-LAN] MAC Randomization, a step further...
Apple is moving forward with their privacy efforts. The next step is to 
randomize MAC addresses when connecting to an AP, not just when probing. This 
is coming soon.

https://globalreachtech.com/blog-mac-randomisation-apple/<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fglobalreachtech.com%2Fblog-mac-randomisation-apple%2F=02%7C01%7Ctim.cappalli%40MICROSOFT.COM%7C1ebf180de6a242fb0aa308d82513081c%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637300110960909491=EAngi4I6yxsqvvG1BzQiNt04FeJ7B37%2Bw%2BvGvE%2BJ24w%3D=0>

This is from Apple. Luckily, there is a way to disable private addresses. I 
just don’t know if it will be ON by default.
https://support.apple.com/en-qa/HT211227<https://nam06.safelinks.protection.outlook.com/?url=https

RE: [WIRELESS-LAN] MAC Randomization, a step further...

[Floyd, Brad]

Maybe a good use case for IPv6

From: The EDUCAUSE Wireless Issues Community Group Listserv 
[mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU] On Behalf Of Enfield, Chuck
Sent: Friday, July 10, 2020 3:49 PM
To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
Subject: [EXTERNAL]Re: [WIRELESS-LAN] MAC Randomization, a step further...

Uhg.  Didn’t even think about that.

From: The EDUCAUSE Wireless Issues Community Group Listserv 
mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>> 
On Behalf Of Eric LaCroix
Sent: Friday, July 10, 2020 4:48 PM
To: 
WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU<mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>
Subject: Re: [WIRELESS-LAN] MAC Randomization, a step further...

We’re all going to need to check the TTL on DHCP leases… some of our scopes 
will get eaten alive otherwise.

From: The EDUCAUSE Wireless Issues Community Group Listserv 
mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>> 
on behalf of "Floyd, Brad" mailto:bfl...@mail.smu.edu>>
Reply-To: The EDUCAUSE Wireless Issues Community Group Listserv 
mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>>
Date: Friday, July 10, 2020 at 3:42 PM
To: 
"WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU<mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>" 
mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>>
Subject: Re: [WIRELESS-LAN] MAC Randomization, a step further...

Thanks Tim. I just started a conversation with my SE.
Brad

From: The EDUCAUSE Wireless Issues Community Group Listserv 
[mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU] On Behalf Of Tim Cappalli
Sent: Friday, July 10, 2020 2:07 PM
To: 
WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU<mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>
Subject: [EXTERNAL]Re: [WIRELESS-LAN] MAC Randomization, a step further...

For extended visitor use cases (over 1 day), Passpoint is really the only 
feasible solution moving forward. Aruba has a Passpoint offering/service called 
Air Pass and WBA’s OpenRoaming initiative is gaining a lot of support.

tim

From: The EDUCAUSE Wireless Issues Community Group Listserv 
mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>>
Date: Friday, July 10, 2020 at 15:04
To: 
WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU<mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU> 
mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>>
Subject: Re: [WIRELESS-LAN] MAC Randomization, a step further...
Tim,
Anything in the works from Aruba about how best to deal with ClearPass Guest 
MAC Auth?
Thanks,
Brad

From: The EDUCAUSE Wireless Issues Community Group Listserv 
[mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU] On Behalf Of Tim Cappalli
Sent: Friday, July 10, 2020 2:01 PM
To: 
WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU<mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>
Subject: [EXTERNAL]Re: [WIRELESS-LAN] MAC Randomization, a step further...

Connected MAC randomization on iOS will be enabled by default, just like on 
Android (starting in 10).

Two major differences:
1)  iOS does not expose the randomization knob (to disable it) to end users 
during initial connection. It is available after connection in the saved 
network list
2)  On Android (version 10 and 11), the MAC is set once per ESSID for the 
lifetime of the OS instance (aka until a factory reset). On iOS 14, the MAC is 
set per ESSID and is changed once every 24 hours.

Note that Android 11 has a developer option to enable a per-connection MAC 
which likely indicates this will enabled by default or exposed to users in 
Android 12.

tim

From: The EDUCAUSE Wireless Issues Community Group Listserv 
mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>>
Date: Friday, July 10, 2020 at 14:57
To: 
WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU<mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU> 
mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>>
Subject: [WIRELESS-LAN] MAC Randomization, a step further...
Apple is moving forward with their privacy efforts. The next step is to 
randomize MAC addresses when connecting to an AP, not just when probing. This 
is coming soon.

https://globalreachtech.com/blog-mac-randomisation-apple/<https://nam01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fglobalreachtech.com%2Fblog-mac-randomisation-apple%2F=02%7C01%7Ccae104%40PSU.EDU%7C6ca8f8e4031a4b3de23508d825127ee1%7C7cf48d453ddb4389a9c1c115526eb52e%7C0%7C0%7C637300108662501805=U5odswVITO9YivbJSE8WrQATASb9C7DY0RLaymxC%2Bb0%3D=0>

This is from Apple. Luckily, there is a way to disable private addresses. I 
just don’t know if it will be ON by default.
https://support.apple.com/en-qa/HT211227<https://nam01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fsupport.apple.com%2Fen-qa%2FHT211227=02%7C01%7Ccae104%40PSU.EDU%7C6ca8f8e4031a4b3de23508d825127ee1%7C7cf48d453ddb4389a9c1c115526eb52e%7C0%7C0%7C637300108662511799=df8UN1GqkmISSApL0dKgtLMrQzXgCTTK1bFIGXPw78I%3D=0>

Happy Friday!

Hector Rios, Wireless Network Architect
The University of Texas at Austin


**
Replies to EDUCAUSE Community Group emails are sent to the entire community 
list. If you want to reply only to 

RE: [WIRELESS-LAN] MAC Randomization, a step further...

[Enfield, Chuck]

Uhg.  Didn’t even think about that.

From: The EDUCAUSE Wireless Issues Community Group Listserv 
 On Behalf Of Eric LaCroix
Sent: Friday, July 10, 2020 4:48 PM
To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
Subject: Re: [WIRELESS-LAN] MAC Randomization, a step further...

We’re all going to need to check the TTL on DHCP leases… some of our scopes 
will get eaten alive otherwise.

From: The EDUCAUSE Wireless Issues Community Group Listserv 
 on behalf of "Floyd, Brad" 

Reply-To: The EDUCAUSE Wireless Issues Community Group Listserv 

Date: Friday, July 10, 2020 at 3:42 PM
To: "WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU" 
Subject: Re: [WIRELESS-LAN] MAC Randomization, a step further...

Thanks Tim. I just started a conversation with my SE.
Brad

From: The EDUCAUSE Wireless Issues Community Group Listserv 
[mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU] On Behalf Of Tim Cappalli
Sent: Friday, July 10, 2020 2:07 PM
To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
Subject: [EXTERNAL]Re: [WIRELESS-LAN] MAC Randomization, a step further...

For extended visitor use cases (over 1 day), Passpoint is really the only 
feasible solution moving forward. Aruba has a Passpoint offering/service called 
Air Pass and WBA’s OpenRoaming initiative is gaining a lot of support.

tim

From: The EDUCAUSE Wireless Issues Community Group Listserv 
mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>>
Date: Friday, July 10, 2020 at 15:04
To: 
WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU<mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU> 
mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>>
Subject: Re: [WIRELESS-LAN] MAC Randomization, a step further...
Tim,
Anything in the works from Aruba about how best to deal with ClearPass Guest 
MAC Auth?
Thanks,
Brad

From: The EDUCAUSE Wireless Issues Community Group Listserv 
[mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU] On Behalf Of Tim Cappalli
Sent: Friday, July 10, 2020 2:01 PM
To: 
WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU<mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>
Subject: [EXTERNAL]Re: [WIRELESS-LAN] MAC Randomization, a step further...

Connected MAC randomization on iOS will be enabled by default, just like on 
Android (starting in 10).

Two major differences:

  1.  iOS does not expose the randomization knob (to disable it) to end users 
during initial connection. It is available after connection in the saved 
network list
  2.  On Android (version 10 and 11), the MAC is set once per ESSID for the 
lifetime of the OS instance (aka until a factory reset). On iOS 14, the MAC is 
set per ESSID and is changed once every 24 hours.

Note that Android 11 has a developer option to enable a per-connection MAC 
which likely indicates this will enabled by default or exposed to users in 
Android 12.

tim

From: The EDUCAUSE Wireless Issues Community Group Listserv 
mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>>
Date: Friday, July 10, 2020 at 14:57
To: 
WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU<mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU> 
mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>>
Subject: [WIRELESS-LAN] MAC Randomization, a step further...
Apple is moving forward with their privacy efforts. The next step is to 
randomize MAC addresses when connecting to an AP, not just when probing. This 
is coming soon.

https://globalreachtech.com/blog-mac-randomisation-apple/<https://nam01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fglobalreachtech.com%2Fblog-mac-randomisation-apple%2F=02%7C01%7Ccae104%40PSU.EDU%7C6ca8f8e4031a4b3de23508d825127ee1%7C7cf48d453ddb4389a9c1c115526eb52e%7C0%7C0%7C637300108662501805=U5odswVITO9YivbJSE8WrQATASb9C7DY0RLaymxC%2Bb0%3D=0>

This is from Apple. Luckily, there is a way to disable private addresses. I 
just don’t know if it will be ON by default.
https://support.apple.com/en-qa/HT211227<https://nam01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fsupport.apple.com%2Fen-qa%2FHT211227=02%7C01%7Ccae104%40PSU.EDU%7C6ca8f8e4031a4b3de23508d825127ee1%7C7cf48d453ddb4389a9c1c115526eb52e%7C0%7C0%7C637300108662511799=df8UN1GqkmISSApL0dKgtLMrQzXgCTTK1bFIGXPw78I%3D=0>

Happy Friday!

Hector Rios, Wireless Network Architect
The University of Texas at Austin


**
Replies to EDUCAUSE Community Group emails are sent to the entire community 
list. If you want to reply only to the person who sent the message, copy and 
paste their email address and forward the email reply. Additional participation 
and subscription information can be found at 
https://www.educause.edu/community<https://nam01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.educause.edu%2Fcommunity=02%7C01%7Ccae104%40PSU.EDU%7C6ca8f8e4031a4b3de23508d825127ee1%7C7cf48d453ddb4389a9c1c115526eb52e%7C0%7C0%7C637300108662511799=z1u67M2qM9yLcYTjA3JbaPzTK3r9HLqbcqc8A2n2Rbk%3D=0>

**
Replies to EDUCAUSE Community Group emails are sent to the entire community 
list. If you want to reply only to the person who sent the message, copy and 
paste their email address and forward the email repl

Re: [WIRELESS-LAN] MAC Randomization, a step further...

[Eric LaCroix]

We’re all going to need to check the TTL on DHCP leases… some of our scopes 
will get eaten alive otherwise.

From: The EDUCAUSE Wireless Issues Community Group Listserv 
 on behalf of "Floyd, Brad" 

Reply-To: The EDUCAUSE Wireless Issues Community Group Listserv 

Date: Friday, July 10, 2020 at 3:42 PM
To: "WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU" 
Subject: Re: [WIRELESS-LAN] MAC Randomization, a step further...

Thanks Tim. I just started a conversation with my SE.
Brad

From: The EDUCAUSE Wireless Issues Community Group Listserv 
[mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU] On Behalf Of Tim Cappalli
Sent: Friday, July 10, 2020 2:07 PM
To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
Subject: [EXTERNAL]Re: [WIRELESS-LAN] MAC Randomization, a step further...

For extended visitor use cases (over 1 day), Passpoint is really the only 
feasible solution moving forward. Aruba has a Passpoint offering/service called 
Air Pass and WBA’s OpenRoaming initiative is gaining a lot of support.

tim

From: The EDUCAUSE Wireless Issues Community Group Listserv 
mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>>
Date: Friday, July 10, 2020 at 15:04
To: 
WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU<mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU> 
mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>>
Subject: Re: [WIRELESS-LAN] MAC Randomization, a step further...
Tim,
Anything in the works from Aruba about how best to deal with ClearPass Guest 
MAC Auth?
Thanks,
Brad

From: The EDUCAUSE Wireless Issues Community Group Listserv 
[mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU] On Behalf Of Tim Cappalli
Sent: Friday, July 10, 2020 2:01 PM
To: 
WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU<mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>
Subject: [EXTERNAL]Re: [WIRELESS-LAN] MAC Randomization, a step further...

Connected MAC randomization on iOS will be enabled by default, just like on 
Android (starting in 10).

Two major differences:

  1.  iOS does not expose the randomization knob (to disable it) to end users 
during initial connection. It is available after connection in the saved 
network list
  2.  On Android (version 10 and 11), the MAC is set once per ESSID for the 
lifetime of the OS instance (aka until a factory reset). On iOS 14, the MAC is 
set per ESSID and is changed once every 24 hours.

Note that Android 11 has a developer option to enable a per-connection MAC 
which likely indicates this will enabled by default or exposed to users in 
Android 12.

tim

From: The EDUCAUSE Wireless Issues Community Group Listserv 
mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>>
Date: Friday, July 10, 2020 at 14:57
To: 
WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU<mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU> 
mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>>
Subject: [WIRELESS-LAN] MAC Randomization, a step further...
Apple is moving forward with their privacy efforts. The next step is to 
randomize MAC addresses when connecting to an AP, not just when probing. This 
is coming soon.

https://globalreachtech.com/blog-mac-randomisation-apple/<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fglobalreachtech.com%2Fblog-mac-randomisation-apple%2F=02%7C01%7Ctim.cappalli%40MICROSOFT.COM%7C26fc195c29b4457a06d508d825041970%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637300046829877974=igFSatWaHCRzls6rl4jmDkuFMSPjuntnUMWZxFGbHFA%3D=0>

This is from Apple. Luckily, there is a way to disable private addresses. I 
just don’t know if it will be ON by default.
https://support.apple.com/en-qa/HT211227<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fsupport.apple.com%2Fen-qa%2FHT211227=02%7C01%7Ctim.cappalli%40MICROSOFT.COM%7C26fc195c29b4457a06d508d825041970%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637300046829887971=g0uQmC7cCwUEiW62uzXILQWWJtyhlm%2Bv1JhrspVG0ec%3D=0>

Happy Friday!

Hector Rios, Wireless Network Architect
The University of Texas at Austin


**
Replies to EDUCAUSE Community Group emails are sent to the entire community 
list. If you want to reply only to the person who sent the message, copy and 
paste their email address and forward the email reply. Additional participation 
and subscription information can be found at 
https://www.educause.edu/community<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.educause.edu%2Fcommunity=02%7C01%7Ctim.cappalli%40MICROSOFT.COM%7C26fc195c29b4457a06d508d825041970%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637300046829897966=Ma2mA8RDW7QHHZ5kPBEGpOZIgn6EK%2FTJBmSYird3aI8%3D=0>

**
Replies to EDUCAUSE Community Group emails are sent to the entire community 
list. If you want to reply only to the person who sent the message, copy and 
paste their email address and forward the email reply. Additional participation 
and subscription information can be found at 
https://www.educause.edu/community<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.educause.edu%2Fcommunity=02%7C01%7Ctim.cappalli%40MICROSOF

RE: [WIRELESS-LAN] MAC Randomization, a step further...

[Enfield, Chuck]

That’s not what our guest network is for.

From: The EDUCAUSE Wireless Issues Community Group Listserv 
 On Behalf Of Friskney, Doyle N.
Sent: Friday, July 10, 2020 4:41 PM
To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
Subject: Re: [WIRELESS-LAN] MAC Randomization, a step further...

This approach will satisfy many IT staff but not many faculty, staff, students.

doyle

Doyle Friskney Ed.D.
Senior Fellow
Kentucky Council on Post Secondary Education
Frankfort, Kentucky&
Adjunct Faculty @ University of Kentucky
College of Communication & Information
859-576-4000


From: The EDUCAUSE Wireless Issues Community Group Listserv 
mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>> 
on behalf of "Enfield, Chuck" mailto:cae...@psu.edu>>
Reply-To: The EDUCAUSE Wireless Issues Community Group Listserv 
mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>>
Date: Friday, July 10, 2020 at 4:37 PM
To: 
"WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU<mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>" 
mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>>
Subject: Re: [WIRELESS-LAN] MAC Randomization, a step further...

CAUTION: External Sender

PS – My plan for supporting our guest network will be to tell any user who 
contacts us with an Apple device that the network is fine and they should 
contact Apple for device support.  I can’t get away with that for our 
enterprise network, but Apple is going to own the guest problem.

From: The EDUCAUSE Wireless Issues Community Group Listserv 
mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>> 
On Behalf Of Enfield, Chuck
Sent: Friday, July 10, 2020 4:34 PM
To: 
WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU<mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>
Subject: Re: [WIRELESS-LAN] MAC Randomization, a step further...

My point wasn’t to debate Passpoint either.  I’m wondering if Apple actually 
has a plan, and if so, if they’ve bothered to tell anybody.

From: The EDUCAUSE Wireless Issues Community Group Listserv 
mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>> 
On Behalf Of Tim Cappalli
Sent: Friday, July 10, 2020 4:22 PM
To: 
WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU<mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>
Subject: Re: [WIRELESS-LAN] MAC Randomization, a step further...

Passpoint is not just about mobile network operators. Any identity provider can 
provision a Passpoint profile. That is the whole drive behind OpenRoaming. The 
industry goal is that every user has at least 2 Passpoint profiles on their 
devices: one tied to their enterprise/school identity and the other tied to a 
personal identity. The traditional enterprise/school onboarding process stays 
largely the same, except some additional Passpoint logic is added.

Mobile network operators / cell providers are only one (optional) piece of the 
puzzle.

Probably should start a separate thread for anything deeper on Passpoint beyond 
it being a solution for network access. Don’t want to take away from the OG 
conversation.

tim

From: The EDUCAUSE Wireless Issues Community Group Listserv 
mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>>
Date: Friday, July 10, 2020 at 16:17
To: 
WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU<mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU> 
mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>>
Subject: Re: [WIRELESS-LAN] MAC Randomization, a step further...
Understood, but few Wi-Fi operators actually support Passpoint on their 
networks.  Since Apple is eliminating the alternatives, they either must be 
idiots (my bet) or have a proposal for what we should all being doing instead.

I still get really confused looks when I try to discuss Passpoint with my 
contacts at the major cellular providers, so it can’t possibly be a realistic 
option for most of us.

From: The EDUCAUSE Wireless Issues Community Group Listserv 
mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>> 
On Behalf Of Tim Cappalli
Sent: Friday, July 10, 2020 4:07 PM
To: 
WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU<mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>
Subject: Re: [WIRELESS-LAN] MAC Randomization, a step further...

Not sure I follow. Passpoint is an industry-wide solution for secure Wi-Fi 
roaming. Passpoint has been supported on iOS and macOS (along with Windows and 
Android) for a number of years.

I definitely don’t follow this comment: “you can’t onboard your Apple to enable 
identity-based auth.”

tim


From: The EDUCAUSE Wireless Issues Community Group Listserv 
mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>>
Date: Friday, July 10, 2020 at 16:04
To: 
WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU<mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU> 
mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>>
Subject: Re: [WIRELESS-LAN] MAC Randomization, a step further...
So you can’t use an Apple MAC address for guest auth, and you can’t onboard 
your Apple to enable identity-based auth.  Apple must be thinking that they can 
drag the entire world, kicking and screaming, into federated authentication 
that Apple products ship knowing how to do (Pa

Re: [WIRELESS-LAN] MAC Randomization, a step further...

[Friskney, Doyle N.]

This approach will satisfy many IT staff but not many faculty, staff, students.

doyle

Doyle Friskney Ed.D.
Senior Fellow
Kentucky Council on Post Secondary Education
Frankfort, Kentucky&
Adjunct Faculty @ University of Kentucky
College of Communication & Information
859-576-4000


From: The EDUCAUSE Wireless Issues Community Group Listserv 
 on behalf of "Enfield, Chuck" 

Reply-To: The EDUCAUSE Wireless Issues Community Group Listserv 

Date: Friday, July 10, 2020 at 4:37 PM
To: "WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU" 
Subject: Re: [WIRELESS-LAN] MAC Randomization, a step further...

CAUTION: External Sender

PS – My plan for supporting our guest network will be to tell any user who 
contacts us with an Apple device that the network is fine and they should 
contact Apple for device support.  I can’t get away with that for our 
enterprise network, but Apple is going to own the guest problem.

From: The EDUCAUSE Wireless Issues Community Group Listserv 
 On Behalf Of Enfield, Chuck
Sent: Friday, July 10, 2020 4:34 PM
To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU
Subject: Re: [WIRELESS-LAN] MAC Randomization, a step further...

My point wasn’t to debate Passpoint either.  I’m wondering if Apple actually 
has a plan, and if so, if they’ve bothered to tell anybody.

From: The EDUCAUSE Wireless Issues Community Group Listserv 
mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>> 
On Behalf Of Tim Cappalli
Sent: Friday, July 10, 2020 4:22 PM
To: 
WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU<mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>
Subject: Re: [WIRELESS-LAN] MAC Randomization, a step further...

Passpoint is not just about mobile network operators. Any identity provider can 
provision a Passpoint profile. That is the whole drive behind OpenRoaming. The 
industry goal is that every user has at least 2 Passpoint profiles on their 
devices: one tied to their enterprise/school identity and the other tied to a 
personal identity. The traditional enterprise/school onboarding process stays 
largely the same, except some additional Passpoint logic is added.

Mobile network operators / cell providers are only one (optional) piece of the 
puzzle.

Probably should start a separate thread for anything deeper on Passpoint beyond 
it being a solution for network access. Don’t want to take away from the OG 
conversation.

tim

From: The EDUCAUSE Wireless Issues Community Group Listserv 
mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>>
Date: Friday, July 10, 2020 at 16:17
To: 
WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU<mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU> 
mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>>
Subject: Re: [WIRELESS-LAN] MAC Randomization, a step further...
Understood, but few Wi-Fi operators actually support Passpoint on their 
networks.  Since Apple is eliminating the alternatives, they either must be 
idiots (my bet) or have a proposal for what we should all being doing instead.

I still get really confused looks when I try to discuss Passpoint with my 
contacts at the major cellular providers, so it can’t possibly be a realistic 
option for most of us.

From: The EDUCAUSE Wireless Issues Community Group Listserv 
mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>> 
On Behalf Of Tim Cappalli
Sent: Friday, July 10, 2020 4:07 PM
To: 
WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU<mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>
Subject: Re: [WIRELESS-LAN] MAC Randomization, a step further...

Not sure I follow. Passpoint is an industry-wide solution for secure Wi-Fi 
roaming. Passpoint has been supported on iOS and macOS (along with Windows and 
Android) for a number of years.

I definitely don’t follow this comment: “you can’t onboard your Apple to enable 
identity-based auth.”

tim


From: The EDUCAUSE Wireless Issues Community Group Listserv 
mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>>
Date: Friday, July 10, 2020 at 16:04
To: 
WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU<mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU> 
mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>>
Subject: Re: [WIRELESS-LAN] MAC Randomization, a step further...
So you can’t use an Apple MAC address for guest auth, and you can’t onboard 
your Apple to enable identity-based auth.  Apple must be thinking that they can 
drag the entire world, kicking and screaming, into federated authentication 
that Apple products ship knowing how to do (Passpoint, openroaming, etc.).  Do 
they have a proposal for this that I missed?

From: The EDUCAUSE Wireless Issues Community Group Listserv 
mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>> 
On Behalf Of Rios, Hector J
Sent: Friday, July 10, 2020 2:56 PM
To: 
WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU<mailto:WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU>
Subject: [WIRELESS-LAN] MAC Randomization, a step further...

Apple is moving forward with their privacy efforts. The next step is to 
randomize MAC addresses when connecting to an AP, not just when probing. This 
is coming soon.

https://globalreachte