[Captive-portals] time-based walled gardens

Michael Richardson <mcr+ietf@sandelman.ca> Mon, 10 April 2017 13:19 UTC

Return-Path: <mcr+ietf@sandelman.ca>
X-Original-To: captive-portals@ietfa.amsl.com
Delivered-To: captive-portals@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D6721294AF for <captive-portals@ietfa.amsl.com>; Mon, 10 Apr 2017 06:19:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.502
X-Spam-Level:
X-Spam-Status: No, score=-0.502 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y_XA1scEFu2y for <captive-portals@ietfa.amsl.com>; Mon, 10 Apr 2017 06:19:47 -0700 (PDT)
Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 446001294BD for <captive-portals@ietf.org>; Mon, 10 Apr 2017 06:19:45 -0700 (PDT)
Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 0DC1F203B0 for <captive-portals@ietf.org>; Mon, 10 Apr 2017 09:44:20 -0400 (EDT)
Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 00841636E0 for <captive-portals@ietf.org>; Mon, 10 Apr 2017 09:19:43 -0400 (EDT)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: captive-portals@ietf.org
In-Reply-To: <CADo9JyUr2rpZBjz5zMrrUmi8+gR9VGxBFhMLGVqFGYiWsOic6w@mail.gmail.com>
References: <CADo9JyU2wiEBB4L7ADSybt9se7jCN764JSEoHuGTcuiU_jDscQ@mail.gmail.com> <CAAedzxqR5bWTP_gou+hC5cgQ99tV275nX_ijm7iUok4-h+3wMQ@mail.gmail.com> <CADo9JyVfmhir8YtOR2mzzaaPL_9mBKgFmht6-SA50SfPmh9z6w@mail.gmail.com> <CAAedzxrck9+TBpEp-x8_tG-oxxKh4MQ4-x+iuGNGd6JsG=poQQ@mail.gmail.com> <CADo9JyUKb_c6SPigjUqngUyPvDsbN10TLZX0+B9r92xm6XGgAA@mail.gmail.com> <27524.1491594871@dooku.sandelman.ca> <CAAedzxo3Gp9ZhLeujZBC0vn9GO=+xHxkAstisoUAX1BCTEtYvQ@mail.gmail.com> <CADo9JyUr2rpZBjz5zMrrUmi8+gR9VGxBFhMLGVqFGYiWsOic6w@mail.gmail.com>
X-Mailer: MH-E 8.6; nmh 1.6+dev; GNU Emacs 24.5.1
X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m<nPbLgmtKK-5dC@#:k
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg="pgp-sha256"; protocol="application/pgp-signature"
Date: Mon, 10 Apr 2017 09:19:43 -0400
Message-ID: <23307.1491830383@obiwan.sandelman.ca>
Archived-At: <https://mailarchive.ietf.org/arch/msg/captive-portals/k_hEY71PgYeARyfLbx01ailIapQ>
Subject: [Captive-portals] time-based walled gardens
X-BeenThere: captive-portals@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Discussion of issues related to captive portals <captive-portals.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/captive-portals>, <mailto:captive-portals-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/captive-portals/>
List-Post: <mailto:captive-portals@ietf.org>
List-Help: <mailto:captive-portals-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/captive-portals>, <mailto:captive-portals-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 10 Apr 2017 13:19:49 -0000

David Bird <dbird@google.com> wrote:
    > Should the aim be to provide a
    > general hint of network restriction, or on a per-destination
    > basis?

Consider access to higher bandwidth content (video).
A number of places might want to restrict access to such content during
certain periods, or from certain places.  A school might restrict it
during school hours (simply for fairness: people got other things to do),
yet a teacher ought to be able to stream an instructional video.
Colleges might restrict its use when in a lecture hall.

Airlines might want to restrict streaming video to those who paid more.
(So there might even be multiple levels of walled garden!)

My mobile ISP does not charge me "overages" but, rather limits my bit-rate
after I hit my datacap.  I can buy more; and they SMS me about it, but a
data-only plan wouldn't have an SMS attached to it.

All of these things would seem to be doable with the ICMP plus RESTful
API.    It seems that the session-ID can deal with these changes, and
the validity could indicate things like valid until the end-of-school day.

ICMP says:
   Any change in this value between ICMP messages
   from the same source IP address MUST be considered by the client to
   mean a change in access policy has occurred and previous
   notifications are no longer valid.

I don't know what it means if an ICMP comes from a different source IP.

--
Michael Richardson <mcr+IETF@sandelman.ca>, Sandelman Software Works
 -= IPv6 IoT consulting =-