[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Captive-portals] Arguments against (any) Capport "API"



I am not claiming to have all the answers, or that this is an easy (or a single) problem to solve.  And I reserve the right to be completely wrong :)

Absolutely, as a mobile subscriber with unlimited data who (more or less) trusts my mobile provider, it is also my preference that devices behave as they do today (except when I do interact with 'legitimate' portals, they are often broken or extra annoying because of the browser selection, I sometimes turn off WiFi). I think there are other use-cases and other users have different priorities, trust in network providers, and data plans.

What I think you are illustrating is that it is technically VERY challenging to implement "make before break" for an entire network for all connections in environments that only provide limited access to a limited number of connections (and that it is particularly hard to do this in 'hostile' public access networks where there are commercial incentives for trickery). There are very different cost, benefit, and trust considerations for users. Hopefully, new protocols like QUIC and Capport can make that hand-off smoother, robust, and secure while also allowing users access to resources in public access environments (with or without captive portal and walled garden). 

When I talk about 'public access', I include all Open SSIDs with and without portal, and even some wired environments. As a venue/provider, those are my option when offering public access: a) Wide Open SSID, no portal, few customer complains (and those all get directed to vendors, UE , AP, or ISP), maybe legal issues, probably have squatters hogging bandwidth, b) Open SSID with captive portal, more complaints (which is an ongoing issue that can't as easily dumped onto vendors), but also making money and have branding and analytics to offset the costs of providing public access, fewer problems with squatters, c) do a combination of things, including wired. I talk about 'public access industry' in terms of NASDAQ and private companies that represent an ecosystem where commercial marketing often centers on making it Easy and Secure to get public access around the world... 

When I talk about the difference in behavior UEs have for 'public access' and 'captive portal', I think some pockets of engineers, who have responsibility for the security of their specific users, understand this difference in that you want to protect the user just as much on Open WiFi networks irrespective of the existence of a captive portal (i.e. any public access). I think some UE engineers also feel uncomfortable about supporting Open WiFi at all (and therefore give users warnings), but users demand it -- why? because of public access and ease-of-use. Today most people consider an Open SSID to indicate 'public access'. That SSID may or may not have a portal, full or partial Internet access, or all sorts of man-in-the-middle "applications". Figuring out what trickery is happening in public access networks will always be a moving target... 

What I believe is that public access network providers who use captive portal feel completely justified in doing anything they could otherwise do when users connect to an Open SSID (without captive portal) public access networks. After all, the user trusts the UE, and the UE trusts the user intent to join the Open SSID public access network after it warned the user about the risks. If UE vendors want to change that behavior, I think it is as easy as enforcing the same policy for Open SSID w/o portal as with portal (i.e. a common policy for all public access). There would no longer be incentive to trick UE captive portal detection, because the public access network is being treated the same by the UE regardless. However, this will shift user complaints about public access non-usability, even for Open SSID networks with no portal, to the vendors instead of the network operator. There is a delicate balance there between what users want, what they should want, what they are willing to give up, and what services networks are trying to provide. Venues get all those usability complaints today, and the solutions they come up with are not often elegant. 

As I said, not an easy, or single, problem... And one we can't completely solve (or even try to) in this WG. However, there are things we can do to improve capport nonetheless.


On Fri, Apr 7, 2017 at 9:11 AM, Erik Kline <[email protected]> wrote:
I fundamentally do not understand what it is you're trying to say here.  I apologize for being thick.

The mobile devices with which I am most familiar do "make before break" even for unsecured SSIDs without a captive portal.  They do a few probes of various types and to various destinations (vis. Mariko's research and presentation) on /every/ network before deciding whether to switch general traffic over to it.

(Note that a few apps that style themselves as networking sophisticates may try to fling a few packets on a newly attached network before the OS has done its validation, but those are the very rare exception.  And we see the occasional bug report when they get themselves confused because they haven't waited for the system's detection to do its thing or haven't trusted the detection result.  =)

I don't understand how these mobile devices should be doing something different.  Failing to do what they currently do and going back to "break before make" will not sit well with users.  I personally do not see a solution down that road, but perhaps I misunderstand or others see something I don't yet.

On 8 April 2017 at 00:03, David Bird <[email protected]> wrote:
A root cause of the so-called 'arms race' around captive portal detection that I'm trying to highlight is that it will always continue for as long as UEs treat captive portal networks specifically different than they do public access networks generally, you will have incentive to exploit that difference in behavior in the public access industry.

On Fri, Apr 7, 2017 at 6:52 AM, David Bird <[email protected]> wrote:
On Fri, Apr 7, 2017 at 6:36 AM, Erik Kline <[email protected]> wrote:
I think the client should, ideally do:

-  Use the network for all connections (why ask permission when forgiveness is cheap).

Not gonna happen.  Mobile clients do a ton of work to enable "make before break".  There is no such thing as forgiveness from users who can't get Facebook updates, Twitter notifications, nor email while their device is held hostage because it switched to Wi-Fi and tore down mobile before checking for a captive portal.


But, it DOES happen when you connect to Open SSID without captive portal (or when the venue evaded your detection). Maybe the captive portal networks wants to offer these services in their walled garden... and it is likely the user would be happy about that (provided they selected the network on purpose).

If you had ICMP giving you real-time feedback, you could more accurately (and quickly) detect what connections will work and which will not on the network. QUIC will help in maintaining session continuity as connections are pinned to different interfaces. 

 
This may also address your question elsewhere about browsers and "sandboxing".  I suspect the sandboxing to which you're referring is about cookie isolation (primarily), but there's a kind of "network sanboxing" that is applied as well to ensure the browser uses a self-consistent networking configuration.

Cookie isolation on secure websites doesn't really help the user any...