Re: [Captive-portals] Use Case: "Carrier Grade Captive Portal"

Thanks for your input!... a few comments inline.

On Tue, May 16, 2017 at 9:33 AM, Gunther Nitzsche <[email protected]> wrote:

The different solutions mentioned on this mailing list do not all aim at our
specific scenario; but some do and could help us. I want to pick a few:

Not preferred by us:

* ICMP response:
1) we tunnel our blocked clients via l2tp to a dedicated lns, from
there a GRE
tunnel reaches a squid proxy, redirecting all requests via iptables to
local port 80 and 443.
I doubt that ICMP responses would work here..maybe..

We need to stop the 443 redirecting!

Thus far, I don't see any reason why ICMP wouldn't work. In fact, if *no* ICMP worked, some basic networking stops working (general dest unreach, MTU discovery, etc).

2) more and more providers will use IPv6 and/or NAT Scenarios to
handle their customers
That sounds difficult to implement (icmp via v6 via NAT ..)

There is ICMP for v6 and typically captive portal enforcement happens prior to NAT'ing to the Internet.

3) A lot of customers will have same kind of personal firewall in place
which might
just block any ICMP traffic.

Again, probably not all ICMP is blocked and this becomes UE dependent - e.g. if capport detection uses a raw packet socket it will see packets prior to firewalling.

4) the icmp response may just be ignored and does not force anything

That is by design, in some respects. The "capport compliant" device will not ignore these messages (by definition). "Legacy" devices would ignore them, and they will still depend on the HTTP redirect.

5) the relocation page to be shown instead is probably not part of the
icmp message.

The separation of "configuration" and "notification" is by design.

=> If the customers wants to communicate via a browser, then we should
answer
via the browser. All other separate communication forms may work but are
unreliable
and are dependent on the customer setup.

Increasingly, it is the operating system's captive portal detection that is detecting the need for portal interaction. I agree that it is convenient to have an in-line HTTP response with the redirect or 511 status code, but plain old HTTP is becoming obsolete. Hijacking HTTPS to return a 511 response is a bad idea. The ICMP approach gives 'notification' without requiring (in-line protocol dependent) man-in-the-middle responses and is protocol agnostic.

* DHCP Option: well, that reaches the dhcp-router (cpe), not the
browser of the
customers device. While there is an option "160" to redirect traffic
(RFC 7710) this option is
currently not really supported by vendors. This option is also not
transparent to
the enduser; it will only be received by the cpe. It is still unknown
how the enduser's browser
will be informed through this mechanism.
* no other access mechanisms are covered by this. (e.g. radius) so only
a subset of
users could be reached at all.

* layer 2 solutions: they all do not reach the enduser (at least in our
case:)

It isn't clear to me how subscriber UEs get assigned their IP addresses in your network; they don't use DHCP?

The UE browser will be 'informed' of the captive portal URL by the captive portal detection mechanism (OS/vendor dependent like today). There is a bit of a race condition between the captive portal detection mechanism and the human interacting with the browser in real-time. However, it is possible for browsers (or any Apps) to integrate with the platform captive portal detection service to get additional information like the portal URL. Agreed that UE (and browser) behaviors need to be better defined, but that gets tricky to mandate in RFC, imho. What we can do is define networking 'building blocks' and recommendations on how vendors build user experiences with them.