Subject: Re: [Captive-portals] Starting to discuss Captive Portals

From: Warren Kumari <[email-masked]>
Date: Mon, 20 Apr 2015 17:01:28 -0400

On Mon, Mar 30, 2015 at 11:26 PM, Yaron Sheffer <[email-masked]> wrote:
>> On 30 March 2015 at 15:14, Warren Kumari <[email-masked]> wrote:
>>>
>>> I suspect that we are going to be spending a significant amount of our
>>> time with the tension between making the user's life better, and also
>>> trying to maximize the CP operator's desires.
>>
>>
>> Obviously, because the technical concerns aren't what is hard here.
>>
> We should specify behavior of both the CP and the client. Specifically, the
> client MUST display the CP's web page. And hope that most people obey the
> rules, otherwise we will get into another race between OS vendors and CP
> vendors.

Yup.  Many of the suggestions here (and in a thread in v6@) sound like
they are actually solving "the captive portal problem".... and while I
think that we really should solve the whole problem, I think whatever
we do design will benefit from the information that the client is
behind a CP, and where it is.

So, what I think makes the most sense is to press ahead with this
current document and also keep discussions going on a captive portal
interaction protocol (see below). If that sounds like a good plan,
then I will give the current document one last round of cleanup and
double checking and I will also clarify in the abstract and
introduction that it is not a full "solution" but rather a building
block (that can be used until come up with a final solution)[0]. Joel
(who is sponsoring this doc) sent me mail yesterday asking if it was
ready to be published -- I asked him to hold off because I wanted to
get your input.

>
> And this is my fantasy solution:
>
> /.well-known/captive/status - returns a basic status (CP open/closed), and
> optionally, an expiration time for this information, i.e. when you need to
> poll the status again.
>
> /.well-known/captive/refresh - returns null if no user action is needed
> (rare), or a URL the browser needs to display for the user to beg/pay for
> more time.
>
> The browser could detect these well-known URLs in order to notify the rest
> of the system, or we could wrap them in some fancy JavaScript.
>
> We should still use DHCP to return the address of the resource, so that the
> CP does not need to proxy all IP traffic (it can just drop it, hooray).

It seemed from the BoF that there may enough interest and input to
create a Working Group, problem statement (so we all know what we are
doing, not necessarily to publish), charter, etc.

Currently what I'm thinking a full solution would look like is:
1: A client connects to the CP (after discovering it through probing,
or though the option in the above document).

2: The CP page includes information letting the client know where to
poll for status (in case the web / status interface is not on the same
IP as the CP itself. If we did a ./well-known/ (like Yaron suggests
above) I think some other info that might be useful is:
status (connector or not), time_remaining, time_used, bandwidth/ tier,
URL_to_pay_again, etc.

3: The client uses this to present a warning to the user that their
access is about to expire, and "helpfully" open a page before it does.

Implementing this protocol means that users are (IMO) more likely to
actually use the CP (and so give $$$ to the provider), and presenting
the "renew" page means that users pay again (and presumably also see
the content on the renew page again).

W
[0]: I suspect that getting to a full solution will take a number of
years - I'd personally like to have something that solves at least the
identification problem before that!.

> Thanks,
>         Yaron

-- 
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.
   ---maf

---

From: David Bird <[email-masked]>
Date: Mon, 20 Apr 2015 16:34:03 -0700

Greetings,

I was discussing similar topics with Warren and he suggested I join this
group and introduce myself.

I develop and maintain the open-source captive portal NAS software
CoovaChilli, which forked the ChilliSpot project maybe 8 years ago. The
software is used by many, many hotspots by providers big and small
worldwide. At a minimum, I'm interested in testing and deploying
"solutions" via chilli and can also perhaps provide insight from years of
experience working with captive portal and public access networks.

With respect to discovery of a status 'poll' page, for clients implementing
this ID/RFC, why not give the client the polling URL instead of, or in
combination with, the CP URL? Also, is there any link between the CP DHCP
options and the DHCP lease time?

In the current ID, it says that a CP detection browser should use a
"separate cookie store". This, in my opinion, is the reason for the
"captive portal detection arms race" ... I think it should be stated that a
CP using SSL (that verifies) should use the standard browser context and
only HTTP should use the sandboxed version. This will help promote the use
of SSL for captive portals and will make the user experience more standard
across CP detection browsers.  This will mean it's also recommended that
the CP URL uses a hostname, which seems to conflict with the suggestion in
section 3 that it should be an IP literal.

Regarding polling a special URL from javascript, chilli has such a feature:
http://coova.org/CoovaChilli/JSON

David

On Mon, Apr 20, 2015 at 2:01 PM, Warren Kumari <[email-masked]> wrote:

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

---

From: Warren Kumari <[email-masked]>
Date: Tue, 21 Apr 2015 19:28:21 -0400

[ Top-post ]

David and I had a long chat off-line. I'm responding here as well
(with terse responses) to close the loop.

On Mon, Apr 20, 2015 at 7:34 PM, David Bird <[email-masked]> wrote:
> worldwide. At a minimum, I'm interested in testing and deploying "solutions"
> via chilli and can also perhaps provide insight from years of experience
> working with captive portal and public access networks.
>
> combination with, the CP URL?

This document is intended to simply provide a hint to clients that
they are behind a CP, and how to reach the CP to authenticate.
At the moment there is not standard polling URL format -- I'm hoping
that we do something like form a CaptivePortal working group and
design a CP interaction protocol, which will include a polling format.

> Also, is there any link between the CP DHCP

Nope - this is designed so that an operator can simply add this option
to their DHCP server, without having any changes on the CP itself.
I had initially misunderstood what this question meant -- I had
thought that David was asking if the time in the DHCP lease reflects
the (purchased) access time - it doesn't, because the DHCP server
doesn't know how much time the user will purchase...

> "separate cookie store". This, in my opinion, is the reason for the "captive
> portal detection arms race" ... I think it should be stated that a CP using
> SSL (that verifies) should use the standard browser context and only HTTP
> should use the sandboxed version. This will help promote the use of SSL for
> captive portals and will make the user experience more standard across CP
> detection browsers.  This will mean it's also recommended that the CP URL
> uses a hostname, which seems to conflict with the suggestion in section 3
> that it should be an IP literal.

So, one of the sections that has proved to be problematic in the draft
is the whole "OSs should figure out themselves what to do with this
info. Here is an *example* of what they could do..." -- so, I'm moving
this to an Appendix, and will make it clearer that this is
non-normative, and just an example...

> http://coova.org/CoovaChilli/JSON

Excellent! Expect more mail soon on this topic...

W

---

From: Warren Kumari <[email-masked]>
Date: Wed, 29 Apr 2015 12:49:33 -0400

[ Top post again ]

I wanted to get folks views on the interface exposed by chilli (
http://coova.org/CoovaChilli/JSON ).
It has a simple "status" page (
http://192.168.182.1:3990/json/status?lang=en ), but also provides a
"logon" and "logoff" interface.
In addition to the state (clientState ) the status page also includes
idleTime and inputOctets / outputOctets.
What else do we think the client might need to know? What do folk
think about the additional interfaces (login / logoff)?

Also, Mark and I have requested a BoF slot in Prague -
http://trac.tools.ietf.org/bof/trac/
We will fill this out some more, but we know we'll need to have some
discussions on (potential) charter text, and if any folk would like to
contribute drafts I think that would be very helpful.
IMO some (potentially very drafty) drafts on terminology and a clear
"problem statement" type document (not necessarily to publish, but
simply to make sure we are all on the same page).

Is anyone willing to volunteer for this, or any other documents?

Oh, also I'm assuming folk are OK with my resolution to their comments above?
W

---

From: Martin Thomson <[email-masked]>
Date: Wed, 29 Apr 2015 12:07:58 -0700

> think about the additional interfaces (login / logoff)?

I think that GET requests with side effects like this are dangerous.

More concretely, I think that the following functions are required:

discovery - you need to find who to talk to about these things

status - You need to know what your status is - the identity of this
resource should be learned via discovery.  This needs to be in a
standardized format suitable for machine processing.  This should
include time remaining, and links to the other resources, if they
exist.

logon - you need to know where to log in - this should be a web page,
the location of which is learned from the status resource, and it need
only be present if login is required

logout - if a user is logged in, the status resource might provide
them with a page where they can clear their logout details.  I'd
consider this to be optional.

human-consumption status - a web page that shows status.  I'd consider
this to be optional also.