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

Re: [Captive-portals] time-based walled gardens



Hi Mark,

I was reminded of this thread, as I believe some of the points continue to be on topic.


Networks, particularly public access networks, already do, and will continue to do, all sorts of things we might find questionable - on several levels. We have some questions because the network infrastructure itself has no way to be transparent about the things it does today. It will silently (or at least ideally transparently) hijack HTTP(S). It will silently drop packets not in the walled garden. It will rate-limit packets without indication. With captive portals, that guesswork has led to probing, having to hijack HTTPS (because the UE will not understand a Drop), and other usability problems.


We can remove this UE guesswork by defining how networks *should* implement these enforcement functions, with the proper transparency for the UE to no longer need to guess. This will actually help make the operator more accountable for their enforcement function behavior.


By addressing the core issue of ‘signaling captivity’ at the network layer, we are just annotating (e.g. with ICMP feedback) what is already happening in the network, in real-time, transparently (as in full-disclosure). This, in of itself, does not add new captive portal capabilities - only better information for the UE to provide better user experiences.


What is concerning with the API and direction of the WG, is that we are defining a new form of captivity … “self enforced”. Which will lead to the UEs doing probing to “confirm” the API captivity matches the Network captivity. Networks with API captivity can even be put on top of previously Open WiFi networks (that have no Network captivity). This is new - even if the UE allows the user to ignore the API captivity.


Having written the problem statement, what are your thoughts on the direction today?




On Mon, Apr 10, 2017 at 4:46 PM Mark Nottingham <[email protected]> wrote:

> On 11 Apr 2017, at 1:57 am, Mikael Abrahamsson <[email protected]> wrote:
>
> CAPPORT doesn't have to just solve its own problems, perhaps it'd be good to try to come up with a slightly more generic solution and send it for review in INT-AREA for instance?

If I follow the discussion here and on the issues list correctly, I'm concerned.

My understanding when this WG was chartered was that we didn't really *like* captive portals, but people thought there was some benefit to at least making their operation smoother; we had lots of examples of interop problems and bad user outcomes in the discussion leading up to it. In that manner, the goal here AIUI is to codify current practice and incrementally improve it.

As I said in the BoF, even mitigating those problems might not lead to a great outcome, as it will encourage the deployment of more captive portals (as many networks are rolling them back, at least in my experience).

There is one use case defined in our charter:

"""
Some networks require interaction from users prior to authorizing
network access. Before that authorization is granted, network access
might be limited in some fashion. Frequently, this authorization process
requires human interaction to arrange for payment or to accept some
legal terms.
"""

Expanding the scope of this work to allow networks to further control their users' experience after authorisation to use the network (even if that is just giving a better user experience of that control) is not a small change. Allowing networks to interpose themselves in communication after authorisation is not a small change.

AFAICT addressing these use cases would require re-chartering, and that's something I would argue vigorously against. I'd like to hear a clear statement from the Chairs about what they think the scope of work is here.

Regards,

--
Mark Nottingham   https://www.mnot.net/

_______________________________________________
Captive-portals mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/captive-portals