Subject: Re: [Captive-portals] A view from a WiFi provider on captive portal requirements, challenges and improvements

From: "James Wood" <[email-masked]>
Date: Tue, 18 Apr 2017 16:21:42 +0100

Hi

First of all, great progress appears to have been made with 7710 and
capport/icmp-unreach. Good job!

As a global WiFi provider I would like add our thoughts on the discussions
to date along with my personal views of the problems/challenges we face with
captive portals today. I'm hoping I can contribute to this WG by expressing
views from the 'other side', and why captive portals are still important to
WiFi operators.

Most providers including ourselves require a portal to be displayed for a
number of reasons. Many have already been covered but to confirm, some
countries require (legally) to capture certain information (such as a valid
mobile/cell number to validate it's a real person/device), or accept
T&C's/Privacy policies in respect of the country the hostpot is located.
Other reasons are for advertising, providing seamless logins (i.e. we know
the MAC of the device so we can bypass the portal page and instead present a
welcome back page). But, the real reason most providers insist on a user
going through a portal is to understand who is using their free wifi. There
has to be some payback to the operator/customer and data capture is this.
They may not use the data to market, but just look at how many people
connect and at what times of day etc, or they may send promotional emails to
users who login etc.

So, captive portals are great as a way to onboard and capture some details.

That said, we face daily challenges with captive portals. To name a few:

1. Security. Nobody prefers to join an open network, but most end up doing
because that's the way it is. The hype around Hotspot 2.0 came and went as
that was never really deisgned to help captive portals but rather for
seamless, non-interaction from the user. As a portal provider, we don't want
that, we want to show a portal even if it's just a 'welcome back, you're now
online' message.

2. More devices/browers/web servers are defaulting to checking/redirecting
to a HTTPs URL. As you know, when in a captive portal/walled garden state,
this will cause a problem because you can't intercept a HTTPs request
(rightly so!) to a captive portal page without a browser/certificate
warning. This breaks everything from the end user perspective.

3. Built-in OS captive popups provide limited browser
functionality/cookies/etc. When trying to offer login options like Facebook,
it can really affect the user experience when cookies are not permitted or
other features disabled. The behaviour is also different per device. In
Android 5.0+, the captive portal window immediately dissappears when the
user is authenticated. This is a pain for us as we want to display a "you
are now online" page, or redirect the user to a landing page with
information etc.

4. Walled garden. It's a nightmare having to manage lists of domains/IP's
across all the different vendors kit out there. For example to offer a
social login through Facebook we need to allow certain domains like
facebook.com, akamaihd.net and connect.facebook.net etc. This is all static
lists inside an AP/controller, and would be a nightmare to update should
Facebook change the URLs they send authentication requests throught etc. How
about some way to dynamicly pass back a list of domains as part of the DHCP
option or some other way to allow the operator to set the required domains
at time of connection? Or, how about, as part of the capport API, we are
able to send a list of domains back to the AP, so if someone chooses
Facebook, we open the Facebook domains for that MAC for a few minutes to
allow them to login.

Other thoughts...

I had a look at "draft-wkumari-capport-icmp-unreach-02". I note that it
describes the example URL that could be returned as part of the captive
portal URL: https://wifi.domain.com/portal?icmp_session=10&policy_class=100.
However, what about the other traditional parameters that a captive portal
redirect injects? As a minimum, we need the ap_mac, client_mac and login_url
to which we post the login request back to (traditional captive portal login
request). Without such parameters, we cannot identify the venue/ap/client
and provide the relevant portal splash page and user specific options. I may
have misunderstood this?

Does anyone here see Hotspot 2.0 (release 2 or further in particular) and
OSU as the answer? I don't think I do. It just doesn't seem to help us as a
provider but instead tries to be around getting the user online as quickly
and without any interaction. Providers are all for making it easy for users
to on board, but they need to get something out of it to make it pay. 

I am more than willing to take any questions and offer as much insight as I
can.

Thanks

James

---

From: Joel Jaeggli <[email-masked]>
Date: Tue, 18 Apr 2017 08:36:49 -0700

> On Apr 18, 2017, at 08:21, James Wood <[email-masked]> wrote:
> 
> Hi
> 

Personally it think these are some valuable observations about the goals of the parties offering the service. When we first had a BOF on the captive portal draft it seemed important to me that for the work to be useful it would have to result in a less adversarial approach to interacting with portals. That starts imho with signaling but it gets quickly down to user interface details which is not an area the IETF is traditionally good in.

I hope that portal designers and operators will see interaction and involvement here as worthwhile.

---

From: David Bird <[email-masked]>
Date: Tue, 18 Apr 2017 10:08:42 -0700

Welcome and thanks for the input James!

Comments in-line.

On Tue, Apr 18, 2017 at 8:21 AM, James Wood <[email-masked]>
wrote:

> [snip]
No doubt, Wi-Fi security is important in public access, but I'd argue
outside the scope of the WG. While captive portals are often used on Open
Wi-Fi, they are not limited to public access (there are LTE use-cases, for
example). Also, security in public access transcends L1 security -- do you
trust any wired LAN you plug into while in public places? HS2.0 (more or
less) solves the public Wi-Fi security problem in that users trust their
providers (albeit to varying degrees) and their providers have a
relationship with the HS2.0 network provider. Even if deployed, this
doesn't address situations where users have no trust relationship with the
network provider and still want Wi-Fi (as most people, they assume Apps are
increasingly using TLS and provide end-to-end security).

> warning. This breaks everything from the end user perspective.
Yes, we need to fix this! It is disturbing that vendors commonly hijack
https even with the security errors.

> are now online" page, or redirect the user to a landing page with
Very common problems.

> Facebook, we open the Facebook domains for that MAC for a few minutes to
Managing the walled garden configuration is probably also outside the code
of the WG. I don't think we should have any API inform the client directly
of the walled garden as that information could be misleading, or wrong. I
do agree that the real issue is having the walled garden configuration
synchronized with the NAS/AP ... however, vendors do their own proprietary
ways of doing this already.

> and provide the relevant portal splash page and user specific options. I
This is an area where I expect discussion. If the DHCP server is integrated
with the NAS, then the RFC7710 URL could contain all the necessary
session-specific query string parameters and the additional parameters are
just added. It is also possible that the RFC7710 URL is something like
http://<NAS-IP>/redirect which the NAS responds to with a redirect to
https://<real-portal-domain>/... with all the necessary parameters. This
becomes implementation specific, but all the information required can be
captured one way or another.

> to on board, but they need to get something out of it to make it pay.
I think Hotspot 2.0 has its place and will get deployed... and addresses,
imho, the security of Wi-Fi in public access. It is doing do with security
and "auto-connect" in mind. One issue I think that remains is that post
authentication, HS2.0 doesn't necessarily protect the data-plane on the LAN
or send it back to the operator. I think operators will be selective in
which networks they trust and partner with. I don't think this will replace
captive portals on Open Wi-Fi or elsewhere.

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

---

From: Dave Dolson <[email-masked]>
Date: Tue, 18 Apr 2017 17:18:03 +0000

Regarding the AP/client identification, this is the reason I suggested in an earlier email,
https://mailarchive.ietf.org/arch/msg/captive-portals/RPwEIuLlW6ZSLmEyaqfxgDrF88Q

"
Posting to the create_href:
POST http://<server>/capport/sessions (Accept: application/json)
{ "identity": "<USERNAME>"}

…

The USERNAME could be DHCP option-12 value or MAC address or ?
"

I didn’t know exactly what this identity should be. Maybe multiple identity options are useful.

-Dave

From: Captive-portals [mailto:[email-masked]] On Behalf Of David Bird
Sent: Tuesday, April 18, 2017 1:09 PM
To: James Wood
Cc: [email-masked]
Subject: Re: [Captive-portals] A view from a WiFi provider on captive portal requirements, challenges and improvements

Comments in-line.

On Tue, Apr 18, 2017 at 8:21 AM, James Wood <[email-masked]<mailto:[email-masked]>> wrote:
[snip]

No doubt, Wi-Fi security is important in public access, but I'd argue outside the scope of the WG. While captive portals are often used on Open Wi-Fi, they are not limited to public access (there are LTE use-cases, for example). Also, security in public access transcends L1 security -- do you trust any wired LAN you plug into while in public places? HS2.0 (more or less) solves the public Wi-Fi security problem in that users trust their providers (albeit to varying degrees) and their providers have a relationship with the HS2.0 network provider. Even if deployed, this doesn't address situations where users have no trust relationship with the network provider and still want Wi-Fi (as most people, they assume Apps are increasingly using TLS and provide end-to-end security).

Yes, we need to fix this! It is disturbing that vendors commonly hijack https even with the security errors.

Very common problems.

facebook.com<http://facebook.com>, akamaihd.net<http://akamaihd.net> and connect.facebook.net<http://connect.facebook.net> etc. This is all static

Managing the walled garden configuration is probably also outside the code of the WG. I don't think we should have any API inform the client directly of the walled garden as that information could be misleading, or wrong. I do agree that the real issue is having the walled garden configuration synchronized with the NAS/AP ... however, vendors do their own proprietary ways of doing this already.

Other thoughts...

This is an area where I expect discussion. If the DHCP server is integrated with the NAS, then the RFC7710 URL could contain all the necessary session-specific query string parameters and the additional parameters are just added. It is also possible that the RFC7710 URL is something like http://<NAS-IP>/redirect<http://%3cNAS-IP%3e/redirect> which the NAS responds to with a redirect to https://<real-portal-domain>/<https://%3creal-portal-domain%3e/>... with all the necessary parameters. This becomes implementation specific, but all the information required can be captured one way or another.

I think Hotspot 2.0 has its place and will get deployed... and addresses, imho, the security of Wi-Fi in public access. It is doing do with security and "auto-connect" in mind. One issue I think that remains is that post authentication, HS2.0 doesn't necessarily protect the data-plane on the LAN or send it back to the operator. I think operators will be selective in which networks they trust and partner with. I don't think this will replace captive portals on Open Wi-Fi or elsewhere.

Thanks

James

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

---

From: Erik Kline <[email-masked]>
Date: Wed, 19 Apr 2017 11:05:32 +0900

> identity options are useful.

Or an https://tools.ietf.org/html/rfc7542 style Network Access Identifier.

This may be straying too far into solutioneering too soon, but one outcome
of a captive portal login/auth process might be the negotiation of an NAI
for the UE to present in future session interactions (renewal and
reattachment).