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

[Dave Dolson <[e-mail]>]

Gunther,
My view is that new mechanisms we propose will be used in addition to existing capture/redirect of port 80.
E.g., applied to email, ftp, bittorrent, etc.
When devices support it, and access networks provide it, the user experience will be better. That would be the motivation for deployment.

It does seem like it could take a long time to deploy, but if it is completely backwards compatible and fairly cheap to implement, it might happen.

-Dave


-----Original Message-----
From: Captive-portals [mailto:[e-mail]] On Behalf Of Gunther Nitzsche
Sent: Thursday, May 18, 2017 8:14 AM
To: David Bird
Cc: Heiko Folkerts; [e-mail]; Herzig, Willi
Subject: Re: [Captive-portals] Use Case: "Carrier Grade Captive Portal"

Hello,

thanks for your reply. Let me argue against ..:)

On 17.05.2017 17:11, David Bird wrote:
>
>
> 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).
>  

In a theoretical point of view I absolutely second your opinion. In real
world scenarios I don't see how this
could work out.

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


I guess that is the crux. There are no "capport compliant devices"
outside wifi and there won't be any
for long long time.(as I said: outside the mobile world))  (I may be
wrong here?)
I do not see how to tell Microsoft, Apple, sun/oracle or the linux
community to insert a capport detection inside their
OS. And even if a Windows 11 and a linux kernel 5 would support that,
there will be a
wide majority of devices which would not be updated and will not meet
the criteria and still has to be
handled in a different way.

When the major browsers would support that (like the Chromium Project
for ChromeBooks in
https://www.chromium.org/chromium-os/chromiumos-design-docs/network-portal-detection#TOC-Interpretation-of-Portal-State
)
we might get a step further. But I doubt that the majority of users will
accept permanent "test-traffic" in
normal circumstances.

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

That might be a design error.  Notification is done by the provider, but
configuration (how to react
on e.g. icmp unreachable) is up to the enduser. The provider cannot (and
will not) configure
any customer's client device. Maybe the CPE can be (pre-)configured
(cable-modem/dsl-router) but
not the home-PC. How do I tell the home-PC to open up a specific URL
when capport
detection gets activated (if it would exist)?
 
>
>     => 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.
>

Now let's see how that would look like. If an ICMP unreachable is sent
out to the customer, he will see
an error in the browser. A different one like the ssl-breaking/stopping
error, but still an error.
But what comes next? Now we have lost the only channel to the customer -
the http(s) session
has ended. And we have lost the opportunity to tell the customer's
browser what to show instead.

If we sent out a status code instead we have at least the chance to show
>something< in the
browser which might help the customer to get on the right way. Maybe the
return code
just triggers a warning of the kind "the webserver is unreachable due to
providers action and
asks you to go to <URL> instead" and does not do a redirection by
itself. Everything is better
(for the customers experience, not for the pure theoretical doctrine)
than just showing a
site unreachable.

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

Some do, some don't. cable users do DHCP, DSL customers do radius (via
ppp). Pretty standard stuff. Actually that
doesn't matter a lot, since the connection termination is done by the
CPE, not by the customer's client device (PC).
Even if the cable-modem realizes that something strange is going on, the
home-PC will not be affected by that.

>
> The UE browser will be 'informed' of the captive portal URL by the
> captive portal detection mechanism (OS/vendor dependent like today).

That might be true in the mobile world; For home-pc, small networks. and
so on there is no cpdm which I know of.
(That is why I am here :-)

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

Could you name an example for this? Valid for a standard home-PC ?
And..without having the user to install a cpd - service on his
device? (remember: not mobile)  ("If you want to be our customer you
have to install <this> software here on all your devices; for Ubuntu
please use <this> and for windows XP click <here>.." -> .. will not work)
As I see it there is no detection mechanism in standard OS (outside
wifi) today. And I cannot blame the customer to not have such service
installed if it would exist. It is up to the provider to use the
existing sources and work with the (unknown) equipment of
different customers. So I fear we are stuck to work with the return codes..

> 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.
>
(What is UE ?)


tl;dr :
while I support the opinion to stop breaking/redirecting https and do
proper signaling with icmp instead,
I do not see working setups in real world scenarios without sending a
http-status code leading
to specific browser's behaviour (outside of the mobile world). Otherwise
the customer is left alone with a
browser showing an error page.



(If there would be a possibility to trigger a webpage with a
capportdetection  - icmp unreachable message,
that would be great.. any hints welcome. Very well possible that I just
overlooked something..)


Thanks for listening and sorry for the again (too) long text...

best greetings,
Gunther

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


_______________________________________________
Captive-portals mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/captive-portals