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

From: Heiko Folkerts <[email-masked]>
Date: Wed, 3 May 2017 14:42:50 +0200

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

Do you think that „carrier grade captive portals“ are in scope of the capport 
WG charta? Would the work already done at capport help to cope with this 
problem?
My understanding of the current work in capport is, that it will not solve 
this problem entirely, but I think, it may already be half-way towards a 
solution. Because pushing a customer to a walled garden does not do a status 
change on the client system, but the CPE might work as some kind of “captive 
portal relais”, using at least parts of the current architecture of capport 
on the internal LAN.

Do you think it is usful that the capport WG considers our use case in its 
work? Any help is appreciated.

Best regards,

Heiko.

--
Heiko Folkerts
---------------------------------------------------
Referat CK 15
Federal Office for Information Security (BSI)

Godesberger Allee 185 -189
53175 Bonn
Germany
Telefon:	+49 228 99 9582-5955
Fax:		+49 228 99 10 9582-5955
E-Mail:	[email-masked]
Internet:	www.bsi.bund.de
		www.bsi-fuer-buerger.de

---

From: David Bird <[email-masked]>
Date: Wed, 3 May 2017 06:20:06 -0700

Thanks for your presentation! Yes, I think that use-case fits in with the
group's understanding of captive portals.

Fixing HTTPS hijacking is priority #1 for this WG, imho.

On Wed, May 3, 2017 at 5:42 AM, Heiko Folkerts <[email-masked]>
wrote:

> _______________________________________________
> Captive-portals mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/captive-portals
>

---

From: Dave Dolson <[email-masked]>
Date: Wed, 3 May 2017 13:37:12 +0000

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:[email-masked]] On Behalf Of Heiko Folkerts
Sent: Wednesday, May 3, 2017 8:43 AM
To: [email-masked]
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 the router.

Do you think that „carrier grade captive portals“ are in scope of the capport WG charta? Would the work already done at capport help to cope with this problem?
My understanding of the current work in capport is, that it will not solve this problem entirely, but I think, it may already be half-way towards a solution. Because pushing a customer to a walled garden does not do a status change on the client system, but the CPE might work as some kind of “captive portal relais”, using at least parts of the current architecture of capport on the internal LAN.

Do you think it is usful that the capport WG considers our use case in its work? Any help is appreciated.

Best regards,

Heiko.

---

From: Warren Kumari <[email-masked]>
Date: Thu, 4 May 2017 11:14:31 -0400

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

-- 
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.
   ---maf

---

From: Erik Kline <[email-masked]>
Date: Sun, 7 May 2017 16:45:46 +0900

Agreed.

I wanted to also include an anecdote about a previous boss who had DSL at
home (AT&T, maybe?).  The CPE they gave him threw up a captive portal page
whenever the CPE detected that the DSL link was down.  This seems fairly
useful compared to everything just timing out (of course network
unreachables would have been quick, but somewhat less useful for
non-technical folks, especially given that the portal page could include
the service hotline phone number).

On 5 May 2017 at 00:14, Warren Kumari <[email-masked]> 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.
> >
> >
> > 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:
> >
> > 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),
> >
> > 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.
> >
> > - 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.
> 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 the router.
> >
> > Do you think that „carrier grade captive portals“ are in scope of the
> capport WG charta? Would the work already done at capport help to cope with
> this problem?
> > My understanding of the current work in capport is, that it will not
> solve this problem entirely, but I think, it may already be half-way
> towards a solution. Because pushing a customer to a walled garden does not
> do a status change on the client system, but the CPE might work as some
> kind of “captive portal relais”, using at least parts of the current
> architecture of capport on the internal LAN.
> >

---

From: Mark Nottingham <[email-masked]>
Date: Mon, 8 May 2017 13:28:18 +1000

That's useful as long as the client is a human is behind a browser. It can also break lots of stuff...

Cheers,

> On 7 May 2017, at 5:45 pm, Erik Kline <[email-masked]> wrote:
> 
> Agreed.
> 
> I wanted to also include an anecdote about a previous boss who had DSL at home (AT&T, maybe?).  The CPE they gave him threw up a captive portal page whenever the CPE detected that the DSL link was down.  This seems fairly useful compared to everything just timing out (of course network unreachables would have been quick, but somewhat less useful for non-technical folks, especially given that the portal page could include the service hotline phone number).
> 

--
Mark Nottingham   https://www.mnot.net/

---

From: Michael Richardson <[email-masked]>
Date: Wed, 10 May 2017 08:53:01 -0400

> can also break lots of stuff...

Exactly why the ICMP is useful :-)

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Gunther Nitzsche <[email-masked]>
Date: Tue, 16 May 2017 18:33:35 +0200

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

---

From: David Bird <[email-masked]>
Date: Wed, 17 May 2017 08:11:54 -0700

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

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

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

> 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

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

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

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

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.

---

From: Gunther Nitzsche <[email-masked]>
Date: Thu, 18 May 2017 14:14:10 +0200

Hello,

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

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

---

From: David Bird <[email-masked]>
Date: Thu, 18 May 2017 06:04:00 -0700

> that would be great.. any hints welcome. Very well possible that I just
In my opinion, there already exists an HTTP status code that leads to
specific browser behavior (redirecting to captive portal). The problem is
that even with HTTP (over TLS), this falls apart (without doing 443
hijacking). We could perhaps define something for HTTPS, but are we then
going to make every protocol "captive portal" compliant? Hence the reason
to use ICMP - it will work with any protocol.

---

From: Dave Dolson <[email-masked]>
Date: Thu, 18 May 2017 13:15:31 +0000

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:[email-masked]] On Behalf Of Gunther Nitzsche
Sent: Thursday, May 18, 2017 8:14 AM
To: David Bird
Cc: Heiko Folkerts; [email-masked]; Herzig, Willi
Subject: Re: [Captive-portals] Use Case: "Carrier Grade Captive Portal"

Hello,

 

(What is UE ?)

tl;dr :

best greetings,
Gunther

---

From: Vincent van Dam <[email-masked]>
Date: Thu, 18 May 2017 20:33:53 +0000

> 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

The url is not included in the icmp payload as it would introduce a ddos security risk.

Good point. In the home-network realm, advertising the url using dhcp would also require the CPE to propagate this url to the home network. I agree this would be challenging.

Maybe we can learn/inspire from the “Proposals to discover Provisioning Domains” draft that was shared with this wg earlier this year (https://tools.ietf.org/html/draft-bruneau-pvd-00; note it has been replaced). This draft tackles a similar problem, discovery of the configuration url. In this draft the authors define in chapter 3, they could retrieve what they required by using the “Fully Qualified Domain Name which belongs to the network operator” (chapter 3). And later (4.2) they specify a fixed location where this information can be fetched. Maybe we can use a similar approach. If the UE doesn’t have the url as it would have been advertised in the dhcp, retrieve some config from a fixed url based on the fqdn that belongs to the operator? 

Gr.,
Vincent

________________________________________
Van: Captive-portals [[email-masked]] namens Gunther Nitzsche [[email-masked]]
Verzonden: donderdag 18 mei 2017 14:14
Aan: David Bird
CC: Heiko Folkerts; [email-masked]; Herzig, Willi
Onderwerp: Re: [Captive-portals] Use Case: "Carrier Grade Captive Portal"

Hello,

(What is UE ?)

tl;dr :

best greetings,
Gunther

---

From: Erik Kline <[email-masked]>
Date: Tue, 23 May 2017 22:29:03 +0900

On 19 May 2017 at 05:33, Vincent van Dam <[email-masked]> wrote:

> Good point. In the home-network realm, advertising the url using dhcp
> would also require the CPE to propagate this url to the home network. I
> agree this would be challenging.
>
> Maybe we can learn/inspire from the “Proposals to discover Provisioning
> Domains” draft that was shared with this wg earlier this year (
> https://tools.ietf.org/html/draft-bruneau-pvd-00; note it has been
> replaced). This draft tackles a similar problem, discovery of the
> configuration url. In this draft the authors define in chapter 3, they
> could retrieve what they required by using the “Fully Qualified Domain Name
> which belongs to the network operator” (chapter 3). And later (4.2) they
> specify a fixed location where this information can be fetched. Maybe we
> can use a similar approach. If the UE doesn’t have the url as it would have
> been advertised in the dhcp, retrieve some config from a fixed url based on
> the fqdn that belongs to the operator?
>

That necessitates a UE-side change.  Learning a captive portal URL by means
other than DHCP (which would require router changes as well to somehow
propagate the information into a multi-hop home) certainly does seem worth
considering.

But I'm assuming that operationally HTTP intercept and redirection will
have to persist, until un-upgraded UEs are somehow not worth the effort.

---

From: "Livingood, Jason" <[email-masked]>
Date: Wed, 31 May 2017 22:23:10 +0000

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" <[email-masked] on behalf of [email-masked]> wrote:

---

From: Martin Thomson <[email-masked]>
Date: Thu, 1 Jun 2017 11:07:48 +1000

> 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 maintainin…

Just trying to understand this.  Jason, can you expand on your
assertion that insertion of notices in HTTP messages (I assume
response bodies) is critical to security & integrity?