Steve,
IEEE 802.11’s Random and Changing MAC Address Study Group is
looking at the issue of both privacy and operator impacts of MAC address
randomization. They are in the process of creating a pair of Project
Authorization Requests that will be used to spin up a new IEEE 802.11 task
group to consider what modifications are needed in IEEE 802.11 to support
operator needs while protecting user privacy. The latest version of the privacy
PAR can be found here
<https://mentor.ieee.org/802.11/dcn/20/11-20-0854-02-0rcm-par-proposal-for-privacy.docx>
. The PAR that addresses operational issues can be found here
<https://mentor.ieee.org/802.11/dcn/20/11-20-0742-01-0rcm-proposed-par-draft.docx>
. These are not particularly detailed documents – PARs (and their accompanying
Criteria for Standards Development) are high-level documents that are used to
justify the need for a new task group and to specify the scope of that task
group and the specification(s) it will produce. Once approved, the new task
group will produce either one or more amendments to IEEE 802.11 or it may
produce one or more Recommended Practices, the latter of which can be thought
of as similar to Informational RFCs, while the former are like Standards Track
RFCs.
-Peter Yee
From: Captive-portals [mailto:captive-portals-boun...@ietf.org] On Behalf Of
Steve Haskew
Sent: Friday, July 03, 2020 7:13 AM
To: David Bird; Tommy Pauly
Cc: captive-portals
Subject: Re: [Captive-portals] CAPPORT support in iOS 14 and macOS Big Sur betas
Hi David, Tommy, all,
Just to add the the discussion, from the perspective of a network operator! We
are just implementing and going to be testing this very soon. We don’t see any
issues in terms of policy application, because the final step to log the user
in will be the same with either approach. Actually, this provides a really nice
route for us to resolve the ever-increasing issue of the ugliness of forcing
redirects, especially with the decreasing use of plain HTTP (and therefore
causing SSL warnings). We can only hope that other vendors roll this out soon
too! I see it as a big step forward.
However, the challenge for us that is linked revolves around identity. MAC
Randomisation (also coming in iOS 14) is great for privacy, but in the short
term is poor for user experience on any form of guest wifi, particularly for
longer stays (e.g. hotel, vs cafe). We’ve actually seen a deterioration of
support for Hotspot2.0/Passpoint, in that installation of a profile from within
the Captive Network Assistant on iOS no longer works.
It feels like the dichotomy of privacy vs user experience here has no practical
solutions - could this be something that the wider WG has previously
considered, and is it within the remit of the group to look at?
Thanks,
Steve Haskew
On 3 Jul 2020, at 14:23, David Bird <dbird=40google....@dmarc.ietf.org> wrote:
Thanks Tommy,
Might you have screenshots of the user experience ? I'd be interested to see
it...
Agreed, adopting the new CAPPORT spec is very easy to setup (just a DHCP server
config change at the access point, and an API/Portal server on the Internet).
The complexity for network operators comes when fully integrating this new
"application" method of captive portaling with existing "network"
(NAS/redirect) methods. The complexity is in ensuring the NAS and API are
enforcing the same policies, for all kinds of users (roaming, paid, free, etc)
... if the network operator doesn't do this well, or at all, then the
complexity is shifted to client device support, answering questions like "Why
does the WiFi at airport X not work only for new devices?". For this reason, I
believe you will eventually start probing for redirects again...
You may trust the API, but you may also want to verify.... :)
On Thu, Jul 2, 2020 at 7:24 AM Tommy Pauly <tpa...@apple.com> wrote:
Hi David,
One point I wanted to clarify: the iOS and macOS betas support for CAPPORT
discovery and APIs still goes through the standard and existing UI flow for
captive portals. The times in which the captive portal UI is shown is limited,
for example to times when the user is in WiFi settings. Thus, while adoption
should indeed be easy and only require adding a small bit of infrastructure in
order to provide a flow that doesn’t require redirects, the set of
circumstances in which a network can display content to the user is not
increased.
Thanks,
Tommy
On Jul 1, 2020, at 5:27 PM, David Bird <db...@google.com> wrote:
That's pretty cool!
This will give new opportunities in monetizing WiFi for new iOS and macOS
devices with only a DHCP server change and an API server!
On Wed, Jul 1, 2020 at 4:22 PM Erik Kline <ek.i...@gmail.com> wrote:
+1
Out of curiosity, does the implementation handle the 7710bis options'
urn:ietf:params:capport:unrestricted value?
On Mon, Jun 22, 2020 at 5:00 PM Martin Thomson <m...@lowentropy.net> wrote:
>
> Tommy, this is great! Thanks for all your work here, it's good to see this
> turn into something concrete.
>
> On Tue, Jun 23, 2020, at 07:30, Tommy Pauly wrote:
> > Hello CAPPORT,
> >
> > I wanted to highlight an announcement we’ve made for the betas of iOS
> > and macOS released today:
> >
> > How to modernize your captive network
> > <https://developer.apple.com/news/?id=q78sq5rv>
> >
> > The betas for iOS and macOS support both draft-ietf-capport-rfc7710bis
> > and draft-ietf-capport-api by default. This doesn’t change the user
> > experience of logging onto captive networks, but the system will
> > request the DHCP options and handle the RA option, and will prefer
> > using the Captive Portal API Server interaction over having a probe
> > that is intercepted.
> >
> > If you have a portal system that is already implementing the CAPPORT
> > features, please test out these betas and let us know if you see any
> > issues! And if you have a captive portal solution, we’d encourage you
> > to start supporting this soon.
> >
> > Best,
> > Tommy
> > _______________________________________________
> > Captive-portals mailing list
> > Captive-portals@ietf.org
> > https://www.ietf.org/mailman/listinfo/captive-portals
> >
>
> _______________________________________________
> Captive-portals mailing list
> Captive-portals@ietf.org
> https://www.ietf.org/mailman/listinfo/captive-portals
_______________________________________________
Captive-portals mailing list
Captive-portals@ietf.org
https://www.ietf.org/mailman/listinfo/captive-portals
_______________________________________________
Captive-portals mailing list
Captive-portals@ietf.org
https://www.ietf.org/mailman/listinfo/captive-portals
_______________________________________________
Captive-portals mailing list
Captive-portals@ietf.org
https://www.ietf.org/mailman/listinfo/captive-portals
