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

[Gunther Nitzsche <[e-mail]>]

Hello everybody,

On 03.05.2017 14:42, Heiko Folkerts wrote:

>Hi everybody, I visited the capport WG the first time in Chicago. Thank
you very much for the presentations!
>Afterwards I had a very brief chat with Martin about a use case, I name
“carrier grade captive portals”.
>As a result I want to present this use case to you on this mailing
list: <...>
>...
> carrier grade captive portal (aka walled garden, forced portal),
>
> The most efficient way to inform and get systems cleaned has been
proven is the carrier grade captive portal. One of the 
> internet service providers, NetCologne, uses a, as they call it,
Forced Portal.

That's us :)

Indeed we use this technique for quite a couple of years now. We
realized we had
to inform our customers about blocking (caused by abusive behaviour or by
not paying the bill) in a quick way without causing too much effort at
support
or customers side.

Showing them an informational webpage with the blocking reason (including
an option to unblock themselves) was and is the fastest way to inform
and help the
customer without having too much support trouble (including the option
to reach out for some selected domains for downloading e.g.
antivirus-patterns or
get other kind of help).

That worked pretty well all the years.. until someone implemented
certificate
pinning to protect customers from mitm and phishing attacks. You know the
problems.. 

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..

  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 ..)

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

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

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


=> 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.


* 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:)


From the current solutions so far beeing suggested I strongly
prefer a specific HTTP status return code which will lead to a certain
behaviour on the enduser's browser. The 511 looks promising ..

This will work regardless of the access technology used. It will also
only appear
if the user will use a browser at all, it is no "push" technology.
So we will not catch all situations - if the user only receives e-mail via
this connection we would need additional measures. But in the normal
standard
situation we will reach the customer and can inform him about the
status.

The browser does not need to follow the url given with the return code
silently;
instead it SHOULD show some warning that the shown page is not the one the
user requested originally. While the enduser usually clicks "ok" on
every button
he finds, this information should not be presented as a clickable button but
somehow different. Up to further discussion..



just my 0,02 € :-) ; hope this was useful for the discussion.


best greetings,

Gunther

(sorry about the language errors..)

NetCologne Systemadministration
-- 
NetCologne Gesellschaft für Telekommunikation mbH
Am Coloneum 9 ; 50829 Köln
Geschäftsführer:   
  Timo von Lepel,
  Mario Wilhelm  
Vorsitzender des Aufsichtsrates:
  Dr. Andreas Cerbe
  HRB 25580, AG Köln