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

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



I really appreciate the draft.

There is one thing I really like about the draft, as it operates at a dhcp level the first hint I'm in a CP happens strictly before any connections are formed.. that should help keep things orderly without imposing delays on non-CP scenarios. Unfortunately, because it doesn't help with CP state (just CP enabled network or not) it does add delay for determining state with some, potentially slow, internet server for hosts behind CP that are already whitelisted. For instance, every time I open my laptop in a hotel for 24 hours after signing the T&C.

I also agree with Yaron's thoughts. I think the document acknowledges a few problems that it needs to actually deal with to make this practical

* Capture status
* expected TTL to facilitate orderly renewals - surprise renewals are a real pain point.
* Some kind of authenticable token, separable from the DNS in a https:// CP url, that clients might whitelist or prioritize (perhaps from history)
* how https:// uris deal with revocation (i.e mandate in-band, or mandate whitelisting of revocation check, etc..)



On Mon, Mar 30, 2015 at 12:42 AM, Yaron Sheffer <[email protected]> wrote:
So, here's a few thoughts:

I suggest to add a requirements section. The reasons why other methods suck (Sec. 2) would be a good start, but I suspect there will be additional requirements once a bigger audience looks at this.

I suggest to add an example scenario, such as: Jean goes into a coffee shop. She signals her agreement to the usage terms and fires up her VPN. After an hour, the session expires, and she needs to click "agree" again.

When we add such a scenario, we will most likely recognize that the DHCP option is not sufficient for what we need, even for a basic CP. The document currently even does not define how applications (the browser, other browsers, a mail client, VPN client etc.) can detect that the CP is now "open", let alone reliably detect when it has "closed" again. We should not rely on the legacy detection methods for this, or we will never get rid of them.

Thanks,
        Yaron


On 03/29/2015 07:31 PM, Mark Nottingham wrote:
Hi everybody,

Thanks to those that came to the Bar BoF in Dallas. Feel free to introduce yourselves here.

I think the strongest outcome there was the interest in the draft for a new DHCP option:
   http://tools.ietf.org/html/draft-wkumari-dhc-capport
IIRC Joel said he was considering sponsoring this document; it would be great to get feedback from OS vendors if they haven't seen it yet.

Hotspot 2.0 <https://en.wikipedia.org/wiki/Hotspot_(Wi-Fi)#Hotspot_2.0> has been brought up by a few people as well. AFAICT, it's focused on "roaming" use cases — e.g., allowing mobile carriers to offer wifi services seamlessly. That's interesting, but AIUI not applicable to *many* use cases where captive portals are used.

Thoughts?

The wiki we've been using to keep state is here:
   https://github.com/httpwg/wiki/wiki/Captive-Portals
Feel free to edit, and if it gets unwieldily, we can consider moving it out of that space.

Cheers,

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




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


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