Re: [Captive-portals] CAPPORT support in iOS 14 and macOS Big Sur betas

[David Bird <[e-mail]>]

The observation isn't new
<https://datatracker.ietf.org/meeting/99/materials/slides-99-capport-icmp-01>
:)

The fact that the new spec *creates* a "major support headache" scenario --
(and thus, I don't think "probing" is going away, basically requiring HTTP
redirect to remain as a back-up measure for network notification) -- I
believe is a fundamental short-coming...


On Fri, Jul 3, 2020 at 9:37 AM Steve Haskew <[e-mail]> wrote:

> David,
>
> This is a very good observation - and one that we have had to consider in
> our implementation. The source of the captive status needs to be reliable
> and quick enough to achieve the flow described in section 6 (Example
> Interaction):
>
> "Once the user satisfies the requirements for external network access, the
> client SHOULD query the API server again to verify that it is no longer
> captive.”.
>
> For us, the API saying the user is online but the enforcement device still
> blocking them would be a major support headache, but could be caused by a
> number of different scenarios. This sentence was key in making us seek a
> robust solution to that possibility.
>
> Thanks,
>
> Steve
>
>
> On 3 Jul 2020, at 17:23, David Bird <dbird=[e-mail]>
> wrote:
>
> Thanks Steve, I have no doubt that some operators will implement this very
> well! :-)
>
> Indeed, the login flow is the same through the Portal via API (assuming
> you figure out the "unique device identity" question).. and I'm sure you'll
> have the API server fully integrated with your AAA so that all sorts of
> logout events are handled (e.g. NAS restart, idle timeout, etc).
>
> In the long-tale of public access, I believe users will experience a wide
> range of networks, with various levels of integration. My concern is more
> that users learn (or even told by venue staff) to disable CAPPORT support
> if they find it often "wrong" (e.g. there is a CAPPORT API but no NAS
> enforcement; API says you are logged in, but NAS is dropping/redirecting;
> etc)...
>
> [I personally believe we missed an opportunity to make a more robust
> protocol by directly involving the NAS (for notification of captivity),
> providing a single source of truth...]
>
> On Fri, Jul 3, 2020 at 7:13 AM Steve Haskew <[e-mail]> wrote:
>
>> 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=[e-mail]>
>> 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 <[e-mail]> 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 <[e-mail]> 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 <[e-mail]> 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 <[e-mail]>
>>>> 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
>>>> > > [e-mail]
>>>> > > https://www.ietf.org/mailman/listinfo/captive-portals
>>>> > >
>>>> >
>>>> > _______________________________________________
>>>> > Captive-portals mailing list
>>>> > [e-mail]
>>>> > https://www.ietf.org/mailman/listinfo/captive-portals
>>>>
>>>> _______________________________________________
>>>> Captive-portals mailing list
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/captive-portals
>>>>
>>> _______________________________________________
>> Captive-portals mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/captive-portals
>>
>>
>> _______________________________________________
>> Captive-portals mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/captive-portals
>>
> _______________________________________________
> Captive-portals mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/captive-portals
>
>
>