Yes, sounds like one of the primary use cases we at Comcast tried to cover
(described in RFC 6108, https://tools.ietf.org/html/rfc6108). It is however a
different walled garden compared to the one you saw, Warren. That one is a
closed WG with no Internet access, whereas the other one just channels HTTP to
a proxy that uses ICAP to insert a notification message but all sites are
accessible.
In any case, this is very much in scope IMO – so agree with others here. With
the rise of IoT compromises the need for these sorts of notifications will only
rise and will be critical to maintaining the security & integrity of the
Internet.
- Jason
On 5/4/17, 11:14 AM, "Captive-portals on behalf of Warren Kumari"
wrote:
I *think* that this is quite similar to a captive portal system run by
Comcast -- I recently upgraded my cable-modem (my old one didn't
support v6). This means that I ended up with a new MAC address on the
CM, and Comcast placed me into a walled garden until I signed in (and
they associated my new MAC with my account) -- while a different cause
(new MAC vs malware), the rest is very similar.
So, I think that these would be well within scope.
W
On Wed, May 3, 2017 at 9:37 AM, Dave Dolson wrote:
> I consider this in scope. It is an excellent example of why captive
portals should be handled at the IP layer (layer3) with IP protocols, and are
not only a WiFi (layer 2) problem.
>
>
> -Original Message-
> From: Captive-portals [mailto:captive-portals-boun...@ietf.org] On Behalf
Of Heiko Folkerts
> Sent: Wednesday, May 3, 2017 8:43 AM
> To: captive-portals@ietf.org
> Cc: Herzig, Willi; Gunther Nitzsche
> Subject: [Captive-portals] Use Case: "Carrier Grade Captive Portal"
>
> 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:
>
> *Background and use case:*
> In Germany the Federal Office for Information Security informs the ISPs
with IPs, timestamp and other information of users that are part of a botnet.
The ISPs are informing the users about the infection. We can not inform the
users without the help of the ISP as they are the only ones knowing who is
behind the dynamic IP address users get normally in Germany.
> There are different ways to inform users by the ISPs: e-mail, snail mail
or a 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. The current solution is legal in germany, if the ISPs terms
of service are appropriate.
>
> *Technically it roughly works like this:*
> - When the abuse management system detects that a user is infected, the
CPE customers router connection (PPOE connection) is disconnected and
immediately a new PPOE connection is started.
> - With the new PPOE connection, the CPE customers router gets a new
DNSServer, IP, gateway (policy routing) and is connected to a carrier grade
captive portal.
> - Within the new network connection all traffic is routed through a
HTTP/HTTPS proxy. This proxy allows the user to access selected sites like
informational sites about infections, AV and OS vendors and will otherwise
present an information page to the user. This information page tells the user
about the situation, including information about the infection(s) and instructs
him how to clean the system.
>
> *Problem (almost the same as you know it):* As with captive portals in
local networks this worked pretty well using HTTP.
> Also on Browsers, which first tries a HTTP connection, the information
page is displayed. Problem occurs now with HTTPS. Especially Google Chrome
does no longer connect first using HTTP when the user enters a domain name of a
web page if using HSTS and HSTS preload.
> Connecting with HTTPS, the browser detects a MITM attack (which of course
makes sense, because it is MITM) and does not display the information page.
> Instead an error page is displayed, which generates a whole lot of calls
to the costumer support. An addional problem we encounter is that the well
known detection strategies used by iOS/macOS, Windows and Android for captive
portals do *never* work in our case.
> Reason is that these detection strategies will only test for captive
portals, when the network connection of the actual device (for example using
WiFi) is started new. In our case the customers CPE router gets a new PPPOE
connection, but the client does not detect that the network connection to the
internet was dropped by
