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

From: Darshak Thakore <[email-masked]>
Date: Sun, 2 Apr 2017 20:51:26 +0000

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

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)

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.

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.

Darshak

---

From: David Bird <[email-masked]>
Date: Sun, 2 Apr 2017 15:21:48 -0700

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-masked]>
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.
>
>
>
Right here I think you have clients already doing traditional captive
portal detection -- just in case DHCP was just misconfigured.

> 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-masked]
> https://www.ietf.org/mailman/listinfo/captive-portals
>
>