Re: [Captive-portals] using webpush as a protocol for interaction between captive portal and clients

Hi Darshak,

For the "API" (requirements TBD :) I think the webpush is a 'great idea, why not' suggestion. The one thing, however, I don't think the API is well suited for is defining the constraints of the network and reporting/signaling what is allowed through the walled garden and what is not.

A couple comments in-line.

On Sun, Apr 2, 2017 at 1:51 PM, Darshak Thakore <[email protected]> wrote:

Hi all,

I just wanted to put this out, the (possibly wild) idea is to use the webpush protocol as the mechanism/tunnel by which a captive portal environment (NAS) can send messages to the client. Webpush is pretty well supported in most browsers and mobile platforms.

The (very rough) idea would be that

1. the RFC7710 URI would point to a document that the client can GET upon receipt

Right here I think you have clients already doing traditional captive portal detection -- just in case DHCP was just misconfigured.

2.       one of the things the document would contain would be a webpush subscription resource

3.       the client would use that to create a push subscription (in this case the push server to use would essentially be chosen by the portal operator but we can likely change that)

4.       the client can either provide the push uri to a specific location (identified in step 2) for sending push messages or the push uri could already have been generated by the captive portal prior to step 1

5.       whenever the portal/NAS wants the client to interact in some way (indicate captivity, require creds, require payment, time expiring etc), it can send a push message to the client. This would actually work even in cases where the client may be in sleep mode since the push message would be delivered to the client when it wakes up to retrieve it.

6.       The actual details in the push message could be either a URL to a web page that gets launched in a browser or a JSON payload that the client would consume to interact (in case of constrained clients)

I can assure you, many hotspot venues would love to have stuff pushed to visitors :)

The pros are that we leverage an existing mechanism that is already well supported (and continues to improve moving forward) and the messaging itself would be quite flexible. We also restrict the role of the API Server to be nothing more than a forwarder between the NAS/CP and the client. David has mentioned in the other discussions that he prefers the NAS to be the “source of truth” and with webpush, the NAS can pretty much control what messages it “pushes” to the client.

It would be challenging to mandate the API is in the NAS (you can't necessarily assume the gateway IP is the NAS, for example)... But, this being the mechanism for clients to determine constraints of the network, I believe, has issues with:

UEs will still be doing traditional CP detection, even if it thinks the location is 'capport compliant', just in case the API is wrong (misconfigured, etc).

It would be hard to match the kind of 'granularity' offered by ICMP in signaling what traffic is allowed, restricted by portal, being rate limited, or otherwise being enforced by the NAS. 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...

I’m still thinking thru if this would be work “in addition” to a basic ICMP message or if we can avoid using ICMP altogether in certain cases.

I think we can do some exiting things in the API !

One warning as we discuss the API: It will be hacked, extended, mutated, branched, adapted, "improved", many times over, by many developers, of varying degrees of competency, all around the world. (A key differentiation between Hotspot captive portal services companies is their 'unique and special' way of providing access). On one hand, great for innovation! --- on the other hand, UE capport detection will learn to ignore the often busted API.

Darshak

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