|
There is a risk in specifying the client check RFC7710 URL and also the Legacy HTTP query. The risk is that portal operators will get creative in requiring work-flows involving both—must visit 7710 URL and also the redirected page. I like the idea of specifying what the client should do. But I also think we should label the client fall-back behavior as deprecated, to inform portal operators they should not rely on it in the future. From: Captive-portals [mailto:[email protected]]
On Behalf Of David Bird In your example, you are doing (what I'm calling) Capport and Legacy at the same time. What would you do if Capport indicates YES (you have a portal), but Legacy says, NO (no portal)? Or wise versa? By adding Capport did we make anything
easier? After you had a success, do you ever check again (for when time expired, etc)? Is it possible to 'suggest' that a user go to the captive portal without actually requiring it? (There are a number of use-cases here, my favorite being the offering of free low-tier rate-limited (but no captive portal) access to the Internet,
but with the option of upgrading with paid access. Or, the indicating that time or data is about to run out.) I think we tend to conflate two related, but different, issues... 1) The lack of signaling the existence of a captive portal for non-HTTP port 80 clients, and 2) issues around why OS captive portal detection fails (or is thwarted). The
second issue should be addressed separately, and if that issue didn't exist, then current (OS/browser) detection methods would already be working just fine... I think the client should, ideally do: - Use the network for all connections (why ask permission when forgiveness is cheap). - In Background, detect Capport ICMP, kick off portal notification (in real browser if https), possibly pin that (blocked) flow to an existing (LTE) network - In Background, Kick off Legacy HTTP query and generate a few random packets (to get Capport ICMP SessionID) - if we had rfc7710, we don't really need the Legacy HTTP result if we already see Capport ICMP, but we might compare it to the
rfc7710 URL if we do get it). If Legacy is detected, but no Capport ICMP, then you have no choice but to pin all connection to LTE like you do today. - When the Capport ICMP SessionId has changed (e.g. a Change of Authorization has occurred), go back to step 1. - When (connection non-terminal) Capport ICMP warnings come in for flows, the user gets a 'suggestion' to go to the portal. (A participant at the meeting indicated he was interested in pre-paid LTE use-cases, I believe those use-cases - with rfc7710 RA, at least - are covered here as well.) I realize this is a big ask... :) Wanted to repeat one rational for this from a previous e-mail: I think there are many use-cases for wanting to move beyond the boolean "all or nothing" view of a captive portal networks. From Chicago O'Hare airport offering free access to airline sites, to many developing-world
examples (I like to think operating system update sites should be freely available), even 'human rights' examples in terms of access to government resource (for FREE, in walled garden), I think UEs should be allowing users to take advantage of these free resources... On Wed, Apr 5, 2017 at 6:45 AM, Erik Kline <[email protected]> wrote: I think we can't get away from nodes doing both new style (7710 + yet-to-be-published stuff) and legacy detection. In an increasingly HTTPS-ified world I would expect we'll end up with devices doing something like: [1] if (7710 available) { do 7710 + yet-to-be-published interaction; if (successful HTTPS Internet query) return; } [2] # possibly in parallel with [1] do sacrificial cleartext HTTP request if (rewriting detected) { do legacy interaction; if (success HTTPS Internet query) return; } [3] last ditch effort here I think it's what the majority of client OS vendors do with (first) [3] and (then) [2] that will determine, in a sort of game theoretic sense, how successful [1] will be. If a majority of client OSes implement [3] as "never make this network the default, but some apps can use it via a multiple Provisioning Domain API (to support connecting to printer hotspots, and the like), or new TAPS API, while leaving
(if available) mobile up", then captive portal vendors will at least be incentivized to stop faking out the queries that constitute [2]. If there proves to be some industry support for [1], and ongoing measurements show some meaningful adoption trends, then OS vendors can look at taking action with respect to networks that still only support [2]. This could include things
like de-prioritization in ESSID auto-join algorithms. We'll obviously need to provide value to as many reasonable parties as possible through whatever [1] ultimately becomes but that value can grow over time as functionality is added to address an increasing number of use cases. This is definitely
going to take some time. |