> On Feb 5, 2018, at 4:54 PM, Martin Thomson <martin.thom...@gmail.com> wrote: > > On Tue, Feb 6, 2018 at 8:41 AM, David Bird <db...@google.com> 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”. >
That’s correct—the device chooses how to expose the available interfaces/PvDs to the applications. If we have a cellular connection, for example, we won’t let any application traffic use the Wi-Fi network until we’re sure that it’s not captive (as far as we can tell). >> 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. Right, we can’t know for sure that the network isn’t lying. We have to trust that in the same way we trust the provisioning of DHCP, etc. We don’t need to make it such that no captive network can pretend to be non-captive, but we do need to allow some captive networks let the devices known that they are captive. > >> 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. An idle device will still time out if nothing checks in, but for a device that is actively using the network and will be timeout at some specific threshold, it is useful to allow the user to re-up the connection. > > _______________________________________________ > 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
