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

David Bird <dbird@google.com> Fri, 03 July 2020 17:55 UTC

Return-Path: <dbird@google.com>
X-Original-To: captive-portals@ietfa.amsl.com
Delivered-To: captive-portals@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 19FEC3A0C90 for <captive-portals@ietfa.amsl.com>; Fri, 3 Jul 2020 10:55:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -17.599
X-Spam-Level:
X-Spam-Status: No, score=-17.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lgho3HL_rcWx for <captive-portals@ietfa.amsl.com>; Fri, 3 Jul 2020 10:54:59 -0700 (PDT)
Received: from mail-il1-x12a.google.com (mail-il1-x12a.google.com [IPv6:2607:f8b0:4864:20::12a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 720413A0C73 for <captive-portals@ietf.org>; Fri, 3 Jul 2020 10:54:58 -0700 (PDT)
Received: by mail-il1-x12a.google.com with SMTP id r12so20706765ilh.4 for <captive-portals@ietf.org>; Fri, 03 Jul 2020 10:54:58 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=fMn84mN8AHSouEycP9LfqfinFIxTxhhm7i81A9OdAnQ=; b=hCOQxK7qG6vsucnwoQHCyLJ8XjphOq+LUCzJlPDrwBdPJqVe/9g/FJpYbwJwJHAZmA BDpwWuTG4nC3Ax05DenfVnM1JNzTSNbT+rN5kZuV3bVmN8ZfVWAPpmsTMgdXsSmPTnsc irXLtuVbwDLWVgyAy1lzQ75qrs7ZTQKPjY4Qfs80AUb8Yikbmef89gN/Efwd16XTGAtM IG4aacE7Kle/1uR4DxzWsBb4javujS8CHhb8zEKIEKudNSB1Nat5zxeHbWd/zgqm//wZ WNYjJ7zDTOagPG8QFpBTl81fdpgAJEQOdHg+r+BWVxFeI+S5vvBygRisjFxoj+M0471T lqLQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=fMn84mN8AHSouEycP9LfqfinFIxTxhhm7i81A9OdAnQ=; b=lQ2hszv1ywRWdYS5NKaQaRrkQzrmUNfrxy/qBs5uxv0gg1OiREPESyytsWX6CMv0ad JYR5XZgJi7Ifd5w1uOWmmyDuTzsPKQw7iBBRwsgdMLCAidrUthQtzzksQx0tCd23zLlo OzA/LIdd5UMGEAq5sbyFhoatzATy6mmtF8TaOPbkOWzJjEZyxR15+M4S064jlYkbwns9 EcwbdLLtPdAN0NXyPcUMm3Wfa9/mXsujt1kDwkXY/PvFIHYT1wW6YltrcqWxX3O8q+fU QVA9j2SVxDeYyNVX0E5ynpDfNwRvXdV/wzxvzyu6ZBL2bnFNs6NyUbFvsolp9myDCCxr PCEg==
X-Gm-Message-State: AOAM531kqgALzzJ2Z1fOxXi6WVSd5SeOb7/PP5AeoUEHfAz4q9CON/tL oCJ/madb2s/KTmCYRaGxlxg09hHgqq1i8V7rknnaow==
X-Google-Smtp-Source: ABdhPJzGOwC9uBBVKBt/0Pn5/vTL5mfF8dgwSYo7cjAVCu8f8cil/I0xHRMAtTUwqk1jRpADZMVsGquTCjiRhX/EsiE=
X-Received: by 2002:a92:8b0e:: with SMTP id i14mr18001591ild.307.1593798897162; Fri, 03 Jul 2020 10:54:57 -0700 (PDT)
MIME-Version: 1.0
References: <CADo9JyUVZfRSpmjYLxBBH73hd7F-+1hwSbr2qDzriaQjLndmFA@mail.gmail.com> <4E013237-9B3C-426B-961A-878EDFCE4806@apple.com> <CADo9JyWD6=hXtB8RURYtgc_xQhZvO+=iWfJr6zauZ1OtzExOrA@mail.gmail.com> <D41B4C9B-C23B-4357-BCD7-BCC520F6B4A4@boaz.org.uk> <CADo9JyWNvNXrFQ3uMb4eZ4OJMieSYKYwP2Yod-A2zOhx68VAeA@mail.gmail.com> <6F344EAD-88F4-4004-92AB-1F60E3D94D48@boaz.org.uk>
In-Reply-To: <6F344EAD-88F4-4004-92AB-1F60E3D94D48@boaz.org.uk>
From: David Bird <dbird@google.com>
Date: Fri, 3 Jul 2020 10:54:46 -0700
Message-ID: <CADo9JyXDFXA_fGbUuSBfmZsRsm+on1N7saQ+Rv_dczPkxuQnbg@mail.gmail.com>
To: Steve Haskew <steve@boaz.org.uk>
Cc: captive-portals <captive-portals@ietf.org>, Tommy Pauly <tpauly@apple.com>
Content-Type: multipart/alternative; boundary="0000000000001c38f605a98d3905"
Archived-At: <https://mailarchive.ietf.org/arch/msg/captive-portals/0l_MSPyXpEQoQtdgAWs-w19Du4s>
Subject: Re: [Captive-portals] CAPPORT support in iOS 14 and macOS Big Sur betas
X-BeenThere: captive-portals@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Discussion of issues related to captive portals <captive-portals.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/captive-portals>, <mailto:captive-portals-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/captive-portals/>
List-Post: <mailto:captive-portals@ietf.org>
List-Help: <mailto:captive-portals-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/captive-portals>, <mailto:captive-portals-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 03 Jul 2020 17:55:02 -0000

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 <steve@boaz.org.uk> 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=40google.com@dmarc.ietf.org>
> 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 <steve@boaz.org.uk> 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=40google.com@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 <tpauly@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 <dbird@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.ietf@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 <mt@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
>>
> _______________________________________________
> Captive-portals mailing list
> Captive-portals@ietf.org
> https://www.ietf.org/mailman/listinfo/captive-portals
>
>
>