Re: [Captive-portals] I-D Action: draft-ietf-capport-api-00.txt

[Martin Thomson <[e-mail]>]

On Tue, Feb 6, 2018 at 8:41 AM, David Bird <[e-mail]> wrote:
>> I have heard UE vendors express a strong desire to be able to know
>> about status before they attempt to use the network.
>>
>
> Hm, but (assuming you are using the provided network for DNS, CRL checks,
> and the API itself), the UE is *already* using the network.

Not really.  The way I understand it, the UE alters routing tables so
that only applications that explicitly opt in to using the interface
to the network can do so.  That state exists until the network is
given an "all clear".

> I believe this desire on the UE vendor part is a case of 'be careful what
> you wish for' ... Having an API telling you it is "all clear" vs "do
> internal (often sandboxed for various reasons browser) captive portal
> dialog" amounts to making this a configuration of the network administrator
> -- Remember the (current) arms race concerning captive  portal detection?
> Well, the network operator wins with this API (!).

Remember we already concluded that if the network wants to lie about
status, we aren't planning to stop them.  There are still some
discussions to be had about providing incentives to be truthful, but
it's possible that we could never really plumb the depths of that
issue productively, so we've been deferring it.

> Over the years on this list we have seen many use-cases come through, I
> recall:
>
> -  A school/library network that allows most of the Internet, but captures
> and redirects for certain networks / sites
> -  A network allows all sorts of protocols - IMAP, HTTPS, for example -
> but not others - like HTTP, SMTP - and want to redirect / signal portal
> -  A network that allows all Internet traffic, but just at a low QoS tier.
> No "captive" portal, but a portal is  yet available for upgrading tier
> -  Any network that allows a large walled garden, or even a *very large*
> garden, but otherwise has a captive portal
> -  A network that will 99.99% of the time allow all traffic, but will
> (perhaps because of virus detection) interrupts sessions  into captive state
> [technically, this is a "boolean" use-case, but one where polling would just
> be huge noise]

I'd say that the amount of information provided here is rich enough
that you want to talk to a human.  Very few networks permit sending of
arbitrary packets to arbitrary hosts and the receipt of similar.  The
point is to ensure that you are managing expectations.  If I
understand the expression of requirements, the idea is that a UE can
use the boolean signal, but this other stuff is better presented on
the web page.  If the network starts off in a captive state, then that
page will be seen (if there is a human), and maybe not used (if there
isn't).

> Clients that go idle typically have their session terminated - so, yes, it
> does save the user time (depending on "time" is billed - real time vs
> metered, etc).

Right.  Though this is relatively rare in my experience.  In those
cases, I think that the idea is that the client can check with the API
before its time comes due and notice the resulting extension and so go
back to sleep.