Re: [Captive-portals] Arguments against (any) Capport "API"

[David Bird <dbird@google.com>]

On Sun, Apr 9, 2017 at 7:53 PM, Erik Kline <ek@google.com> wrote:

On 8 April 2017 at 04:54, Michael Richardson <mcr+ietf@sandelman.ca> wrote:

David Bird <dbird@google.com> wrote:
    > portal (or when the venue evaded your detection). Maybe the captive
    > portal networks wants to offer these services in their walled
    > garden... and it is likely the user would be happy about that
    > (provided they selected the network on purpose).

Consider a school that uses Google Apps (like my sons').

They run a somewhat loose firewall that blacklists stuff; but probably would
be better off to whitelist things.

The ICMP reply could very well be used to trigger the teacher override.

This is an interesting point.  We should consider what types of access restriction are in scope.

Consider zero-rating, for example.  Should the aim be to provide a general hint of network restriction, or on a per-destination basis?

One difference in consideration is whether interaction with a captive portal could theoretically provide remediation.  If so, perhaps a new code under Destination Unreachable is best, and for those things that are effectively "permanently unreachable" Administratively Prohibited might be the best code.

Doesn't ICMP Dest Unreachable generally "aim to provide a general hint of network restrictions", routing, firewall, or otherwise ? (Should we revisit ICMP in general in light of zero-rating?)

I'm not taking a position on zero-rating, but that is essentially what a walled garden is: content allowed before authorization. One use-case might be designed for zero-rating, others might be to prevent kids from going to unknown resources from the school network.

I don't know how you can mandate that 'authorization' is always free and the walled garden isn't used for zero-rating...