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

[David Bird <[e-mail]>]

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

On Tue, May 16, 2017 at 9:33 AM, Gunther Nitzsche <[e-mail]>
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.