Subject: [Captive-portals] Arguments against (any) Capport "API"

From: David Bird <[email-masked]>
Date: Tue, 4 Apr 2017 12:05:07 -0700

Our charter:

The CAPPORT Working Group will define secure mechanisms and protocols to
- allow endpoints to discover that they are in this sort of limited
environment,
- provide a URL to interact with the Captive Portal,
- allow endpoints to learn about the parameters of their confinement,
- interact with the Captive Portal to obtain information such as status
and remaining access time, and
- optionally, advertise a service whereby devices can enable or disable
access to the Internet without human interaction.

I believe RFC7710 and the Capport ICMP I-D cover #1, 2, 3, and even 4 (on a
very granular level - e.g. a per flow - or a general - status).

While an API could be used for some of 1-4, I'd argue there are fundamental
issues with that direction:

 - If a 'Capport RFC compliant' device does RFC7710 and interacts with an
API that keeps the user captive, while non-Capport legacy devices have NO
limitations (e.g. it was an Open network with mis-configured a DHCP
server), then (as a working group) we failed the user. And, UEs will
basically learn to do Capport AND Legacy 'Discovery' anyway ...

- One main focus / reason for an API is to address the (optional) #5 - with
the desire to automate (or simplify) access. This, to me, is problematic,
because:

-- We tend to ignore what the venue/Hotspot operator wants.. They WANT you
at the captive portal... Hence, why they went out of their way to have a
CAPTIVE portal. We could define an alternative method for the portal, but
why? Do Hotspot operators WANT more interfaces, with unknown user
experiences, that limit their options? There is a reason why in WISPr the
browser method was called the "Universal Access Method"... because, well,
it's universal. (Moreover, Hotspot operators are largely marketing
companies -- they are very used to designing Web user experiences, that is
their business).

-- There IS already an API for automated login and captive portal by-pass,
and venues today make money using it. There is an entire industry around
the aggregation and automatic login into (and securing access at) Hotspot
networks worldwide. Unless there is a business reason for venues and
Hotspot operators to support WISPr AND another API for login, I think the
technical benefits need to be more than obvious.

The one area I do see value in solving is how to get headless IoT devices
on-line on capport networks.. But, in some ways, all we need their is a
WISPr client in the device and an out-of-band way of configuring
credentials into it. That can be solved with existing protocols and
technologies.

David

---

From: Mikael Abrahamsson <[email-masked]>
Date: Tue, 4 Apr 2017 21:43:54 +0200 (CEST)

On Tue, 4 Apr 2017, David Bird wrote:

> The one area I do see value in solving is how to get headless IoT 
> devices on-line on capport networks.. But, in some ways, all we need 
> their is a WISPr client in the device and an out-of-band way of 
> configuring credentials into it. That can be solved with existing 
> protocols and technologies.

I only have experience with captive portals as a user. When I travel the 
world, I have frequently seen captive portal pages that as far as I can 
see, offer nothing apart from a login page. It might have the hotel name 
in there, but that's it. So then I have to manually do something like 
find the piece of paper where my username/password is, and enter that. It 
seems to be only about authenticating me as actually being a resident of 
the hotel or whatever venue it is. Sometimes it seems to be there because 
there are legal requirements for tracking (they will write down a log of 
my room number and username on the paper in a ledger).

It's extremely cumbersome and as far as I can tell, it adds nothing for 
the WISP (at least nothing I can tell) by means of marketing or alike, 
it's only for assuring that people in the street can't just use the wifi.

Do you know the motivation for doing this in the context of your email? Is 
there added cost for them to automate the behavior, as in IPR or other 
licensing cost for them to use the automation tech that perhaps is already 
available in my mobile device?

-- 
Mikael Abrahamsson    email: [email-masked]

---

From: David Bird <[email-masked]>
Date: Tue, 4 Apr 2017 12:51:59 -0700

My opinion is that guessing why venues put up a portal isn't always that
useful. The point is, they *have* a reason. In some countries, there are
legal requirements to display ToS. While we could try to implement ways
around ToS type portals, are we helping the venue be more compliant? In all
jurisdictions? (Some laws *require* the ToS is displayed *every time*).

For some locations, they may simply WANT to annoy you! (While also
collecting per session fees from Boingo or iPass for the privileged of
skipping that annoying portal.) More than likely, however, sites like the
one you mentioned are just themselves concerned about liability and want
that minimal amount of disclaimer...

As a user, you should either be willing to view the portal, pay for ease of
use, or find another network...

David

On Tue, Apr 4, 2017 at 12:43 PM, Mikael Abrahamsson <[email-masked]>
wrote:

> see, offer nothing apart from a login page. It might have the hotel name in
> there, but that's it. So then I have to manually do something like find the
> piece of paper where my username/password is, and enter that. It seems to
> be only about authenticating me as actually being a resident of the hotel
> or whatever venue it is. Sometimes it seems to be there because there are
> legal requirements for tracking (they will write down a log of my room
> number and username on the paper in a ledger).
>
> the WISP (at least nothing I can tell) by means of marketing or alike, it's
> only for assuring that people in the street can't just use the wifi.
>

---

From: Kyle Larose <[email-masked]>
Date: Tue, 4 Apr 2017 20:00:51 +0000

I was sitting in a coffee shop on Saturday in Chicago, and decided to log in to their wifi. It was a captive portal that basically said something like “Hey, we’re giving you this service for free, because we’re [the coffee shop] awesome!”. To log in I just needed to click a button to continue.

The point here, I think, is that the coffee shop is providing this as a service to you, and wants you to know that. I’m not sure how much that is worth to them, but it’s an example of something that isn’t just ToS, and wasn’t terribly intrusive.

From: Captive-portals [mailto:[email-masked]] On Behalf Of David Bird
Sent: Tuesday, April 04, 2017 3:52 PM
To: Mikael Abrahamsson
Cc: [email-masked]
Subject: Re: [Captive-portals] Arguments against (any) Capport "API"

My opinion is that guessing why venues put up a portal isn't always that useful. The point is, they have a reason. In some countries, there are legal requirements to display ToS. While we could try to implement ways around ToS type portals, are we helping the venue be more compliant? In all jurisdictions? (Some laws *require* the ToS is displayed *every time*).

For some locations, they may simply WANT to annoy you! (While also collecting per session fees from Boingo or iPass for the privileged of skipping that annoying portal.) More than likely, however, sites like the one you mentioned are just themselves concerned about liability and want that minimal amount of disclaimer...

As a user, you should either be willing to view the portal, pay for ease of use, or find another network...

David

On Tue, Apr 4, 2017 at 12:43 PM, Mikael Abrahamsson <[email-masked]<mailto:[email-masked]>> wrote:
On Tue, 4 Apr 2017, David Bird wrote:
The one area I do see value in solving is how to get headless IoT devices on-line on capport networks.. But, in some ways, all we need their is a WISPr client in the device and an out-of-band way of configuring credentials into it. That can be solved with existing protocols and technologies.

I only have experience with captive portals as a user. When I travel the world, I have frequently seen captive portal pages that as far as I can see, offer nothing apart from a login page. It might have the hotel name in there, but that's it. So then I have to manually do something like find the piece of paper where my username/password is, and enter that. It seems to be only about authenticating me as actually being a resident of the hotel or whatever venue it is. Sometimes it seems to be there because there are legal requirements for tracking (they will write down a log of my room number and username on the paper in a ledger).

It's extremely cumbersome and as far as I can tell, it adds nothing for the WISP (at least nothing I can tell) by means of marketing or alike, it's only for assuring that people in the street can't just use the wifi.

Do you know the motivation for doing this in the context of your email? Is there added cost for them to automate the behavior, as in IPR or other licensing cost for them to use the automation tech that perhaps is already available in my mobile device?

--
Mikael Abrahamsson    email: [email-masked]<mailto:[email-masked]>

---

From: David Bird <[email-masked]>
Date: Tue, 4 Apr 2017 13:05:26 -0700

Attribution / advertising is a big motivator, at least in the US.

On Tue, Apr 4, 2017 at 1:00 PM, Kyle Larose <[email-masked]> wrote:

> I was sitting in a coffee shop on Saturday in Chicago, and decided to log
> in to their wifi. It was a captive portal that basically said something
> like “Hey, we’re giving you this service for free, because we’re [the
> coffee shop] awesome!”. To log in I just needed to click a button to
> continue.
>
>
>
> The point here, I think, is that the coffee shop is providing this as a
> service to you, and wants you to know that. I’m not sure how much that is
> worth to them, but it’s an example of something that isn’t just ToS, and
> wasn’t terribly intrusive.
>
>
>
> *From:* Captive-portals [mailto:[email-masked]] *On
> Behalf Of *David Bird
> *Sent:* Tuesday, April 04, 2017 3:52 PM
> *To:* Mikael Abrahamsson
> *Cc:* [email-masked]
> *Subject:* Re: [Captive-portals] Arguments against (any) Capport "API"
>
>
>

---

From: Christian Saunders <[email-masked]>
Date: Tue, 4 Apr 2017 20:13:37 +0000

I agree that determining the operators intention for the portal isn't really worthwhile.

On the other hand, it is worth providing the operators with tools to enable as seamless an experience as possible.

Beyond this the operators will sink or swim on their own merits.

Cheers!

Christian
Shaw Communications Inc.

On 17-04-04 02:05 PM, David Bird wrote:
Attribution / advertising is a big motivator, at least in the US.

On Tue, Apr 4, 2017 at 1:00 PM, Kyle Larose <[email-masked]<mailto:[email-masked]>> wrote:
I was sitting in a coffee shop on Saturday in Chicago, and decided to log in to their wifi. It was a captive portal that basically said something like “Hey, we’re giving you this service for free, because we’re [the coffee shop] awesome!”. To log in I just needed to click a button to continue.

From: Captive-portals [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of David Bird
Sent: Tuesday, April 04, 2017 3:52 PM
To: Mikael Abrahamsson
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [Captive-portals] Arguments against (any) Capport "API"

David

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

---

From: David Bird <[email-masked]>
Date: Tue, 4 Apr 2017 14:34:59 -0700

Thanks Christian,

I wanted to high-light something you said:

On Tue, Apr 4, 2017 at 1:13 PM, Christian Saunders <
[email-masked]> wrote:

> * On the other hand, it is worth providing the operators with tools to
> enable as seamless an experience as possible.*
>

This is exactly right... the (consistent) and seamless an experience as
possible.

However, today this sometimes means tricking UE captive portal detection
into not giving you the 'other' browser (sandboxed, incognito, or otherwise
not the browser the user is already logged into sites with). For people who
build fancy websites for Hotspots, you can imagine that is frustrating (to
require users to login, every time, even when your site uses HTTPS and
cookies are "safe").

>> Do you know the motivation for doing this in the context of your email?
>> Is there added cost for them to automate the behavior, as in IPR or other
> Captive-portals mailing [email-masked]://www.ietf.org/mailman/listinfo/captive-portals
>
>
>
> [email-masked]

---

From: Mikael Abrahamsson <[email-masked]>
Date: Wed, 5 Apr 2017 06:19:58 +0200 (CEST)

On Tue, 4 Apr 2017, David Bird wrote:

> skipping that annoying portal.) More than likely, however, sites like 
> the one you mentioned are just themselves concerned about liability and 
> want that minimal amount of disclaimer...

Let me rephrase the question:

Is there today a mechanism widely deployed in mobile devices for free use 
by (for instance) a hotel that just wants to make sure that someone enters 
their credentials (to stop passers-by to use it) and wants to view and 
accept the TOS *once*, and then subsequenty it's ok if you just enter same 
credentials each time you connect and it's fine if the user never sees the 
captive portal for subsequent attempts.

Is this available? In that case, what mechanism is that and where can I 
read up on it?

If it's not available, then that's one thing I think we should do here.

What about an enterprise SSID that allows anyone to connect to it, but the 
only thing you get is a captive portal. After you've accepted terms of 
service and entered username/password, this is now somehow provisioned 
into your device as 802.1x credentials and you then disconnect and 
reconnect with these new credentials, which gives you access as long as 
these credentials are valid?

---

From: Tim Chown <[email-masked]>
Date: Wed, 5 Apr 2017 09:14:16 +0100

> On 5 Apr 2017, at 05:19, Mikael Abrahamsson <[email-masked]> wrote:
> 
> What about an enterprise SSID that allows anyone to connect to it, but the only thing you get is a captive portal. After you've accepted terms of service and entered username/password, this is now somehow provisioned into your device as 802.1x credentials and you then disconnect and reconnect with these new credentials, which gives you access as long as these credentials are valid?

That’s eduroam, used by at least tens of millions of people at higher education and research organisations in over 70 countries, supporting roaming between all participants by default.  Except it skips the captive portal bit; indeed captive portal is expressly forbidden; you purely use 802.1x.  The T&C bit is implicit through your account being provided, and accepting the T&C/AUP of the university/NREN when you sign to get that.

Tim

---

From: David Bird <[email-masked]>
Date: Wed, 5 Apr 2017 06:04:59 -0700

> captive portal for subsequent attempts.
Yes, mechanisms exists today. It is not uncommon, for instance, for the
portal to record your acceptance along with your MAC address and then do
"MAC authentication" for your device for some time thereafter.

The Hotspot portal could also do a lot of things in the website itself to
help with ease of use... (provided you are not using a crippled browser
because of a naive captive portal detector) like remembering your state
from cookies, etc, and logging you in without you noticing.

> If it's not available, then that's one thing I think we should do here.
The mechanisms exists... and, this is very much dependent on the access
policy of the venue -- not all venues will want the same thing.

> service and entered username/password, this is now somehow provisioned into
> your device as 802.1x credentials and you then disconnect and reconnect
> with these new credentials, which gives you access as long as these
> credentials are valid?
>
>
You are describing Hotspot 2.0.

802.1x technology already exists today, but there are reasons for it not
taking off in public access:

- It isn't easy to use (without Hotspot 2.0) and doesn't necessarily mean
you don't have a portal anymore. For instance, what does the network do
when you run out of time? Just dump you off the secure wireless or give you
a portal on the secure wireless?

- Users don't care (and prefer the ease of use)

- I'd argue it gives a FALSE sense of security to users, who are, after
all, using public access with no real trust relationship with the venue or
the network provider. Sure, wireless security moves the bar (a little bit)
in terms of passive attacks, but doesn't protect the user from active
attacks or in-line snooping off the wire. Having users see the SECURE WiFi
indication on public access networks (like they see at home) is misleading.
The user is better off with end-to-end security. As QUIC deploys, perhaps
wireless security in public access will be less of an issue.

[Note: 802.1X can be _implemented_ in ways that still leave the user
vulnerable to active attacks. For instance, with EAP-TTLS, if you don't pin
the profile to a server certificate, your device can be fooled into
revealing your credentials to a rogue AP.]

---

From: David Bird <[email-masked]>
Date: Wed, 5 Apr 2017 06:10:44 -0700

Eduroam, at the end of the day, is not unlike Boingo or iPass. They went
out and negotiated roaming contracts with hotspot providers, in this
education organizations. Of course, part of that negotiation was the T&C
acceptance/compliance. While this is a great example of an aggregate
network and a great use-case for 802.1x, it doesn't offer much guidance for
public access in general.

On Wed, Apr 5, 2017 at 1:14 AM, Tim Chown <[email-masked]> wrote:

> > What about an enterprise SSID that allows anyone to connect to it, but
> the only thing you get is a captive portal. After you've accepted terms of
> That’s eduroam, used by at least tens of millions of people at higher
> education and research organisations in over 70 countries, supporting
> roaming between all participants by default.  Except it skips the captive
> portal bit; indeed captive portal is expressly forbidden; you purely use
> 802.1x.  The T&C bit is implicit through your account being provided, and
> accepting the T&C/AUP of the university/NREN when you sign to get that.
>
> Tim

---

From: Michael Richardson <[email-masked]>
Date: Wed, 05 Apr 2017 09:30:54 -0400

David Bird <[email-masked]> wrote:
    > -- We tend to ignore what the venue/Hotspot operator wants.. They WANT
    > you at the captive portal... Hence, why they went out of their way to
    > have a CAPTIVE portal. We could define an alternative method for the
    > portal, but why? Do Hotspot operators WANT more interfaces, with
    > unknown user experiences, that limit their options? There is a reason
    > why in WISPr the browser method was called the "Universal Access
    > Method"... because, well, it's universal. (Moreover, Hotspot operators
    > are largely marketing companies -- they are very used to designing Web
    > user experiences, that is their business).

That's only one view.

Some operators need a record of who used their network for legal reasons.
It's not all about advertising either; at Midway Airport, it was about
having me pay after my free sample wore off.  At my hotel, it was about
keeping the network from being overrun by riff-raff.

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

---

From: Erik Kline <[email-masked]>
Date: Wed, 5 Apr 2017 22:45:26 +0900

I think we can't get away from nodes doing both new style (7710 +
yet-to-be-published stuff) and legacy detection.  In an increasingly
HTTPS-ified world I would expect we'll end up with devices doing something
like:

    [1]
    if (7710 available) {
        do 7710 + yet-to-be-published interaction;
        if (successful HTTPS Internet query) return;
    }

    [2]    # possibly in parallel with [1]
    do sacrificial cleartext HTTP request
    if (rewriting detected) {
        do legacy interaction;
        if (success HTTPS Internet query) return;
    }

    [3]
    last ditch effort here

I think it's what the majority of client OS vendors do with (first) [3] and
(then) [2] that will determine, in a sort of game theoretic sense, how
successful [1] will be.

If a majority of client OSes implement [3] as "never make this network the
default, but some apps can use it via a multiple Provisioning Domain API
(to support connecting to printer hotspots, and the like), or new TAPS API,
while leaving (if available) mobile up", then captive portal vendors will
at least be incentivized to stop faking out the queries that constitute [2].

If there proves to be some industry support for [1], and ongoing
measurements show some meaningful adoption trends, then OS vendors can look
at taking action with respect to networks that still only support [2].
This could include things like de-prioritization in ESSID auto-join
algorithms.

We'll obviously need to provide value to as many reasonable parties as
possible through whatever [1] ultimately becomes but that value can grow
over time as functionality is added to address an increasing number of use
cases.  This is definitely going to take some time.

---

From: Erik Kline <[email-masked]>
Date: Wed, 5 Apr 2017 22:50:06 +0900

> keeping the network from being overrun by riff-raff.

In one case that was brought to our (Android's) attention, there was a
Wi-Fi provider in a refugee camp who was using the captive portal feature
in their equipment to show a camp information page (where to go for medical
services, which phone numbers to call for XYZ, etc).

Such a use case would argue against bypassing the page via some kind of
auto-sign-in, but might highlight the need for an "information about this
network" URL.

---

From: David Bird <[email-masked]>
Date: Wed, 5 Apr 2017 07:42:05 -0700

In your example, you are doing (what I'm calling) Capport and Legacy at the
same time. What would you do if Capport indicates YES (you have a portal),
but Legacy says, NO (no portal)? Or wise versa? By adding Capport did we
make anything easier?

After you had a success, do you ever check again (for when time expired,
etc)?

Is it possible to 'suggest' that a user go to the captive portal without
actually requiring it? (There are a number of use-cases here, my favorite
being the offering of free low-tier rate-limited (but no captive portal)
access to the Internet, but with the option of upgrading with paid access.
Or, the indicating that time or data is about to run out.)

I think we tend to conflate two related, but different, issues... 1) The
lack of signaling the existence of a captive portal for non-HTTP port 80
clients, and 2) issues around why OS captive portal detection fails (or is
thwarted). The second issue should be addressed separately, and if that
issue didn't exist, then current (OS/browser) detection methods would
already be working just fine...

I think the client should, ideally do:

-  Use the network for all connections (why ask permission when forgiveness
is cheap).
-  In Background, detect Capport ICMP, kick off portal notification (in
real browser if https), possibly pin that (blocked) flow to an existing
(LTE) network
-  In Background, Kick off Legacy HTTP query and generate a few random
packets (to get Capport ICMP SessionID) - if we had rfc7710, we don't
really need the Legacy HTTP result if we already see Capport ICMP, but we
might compare it to the rfc7710 URL if we do get it). If Legacy is
detected, but no Capport ICMP, then you have no choice but to pin all
connection to LTE like you do today.
- When the Capport ICMP SessionId has changed (e.g. a Change of
Authorization has occurred), go back to step 1.
- When (connection non-terminal) Capport ICMP warnings come in for flows,
the user gets a 'suggestion' to go to the portal.

(A participant at the meeting indicated he was interested in pre-paid LTE
use-cases, I believe those use-cases - with rfc7710 RA, at least -  are
covered here as well.)

I realize this is a big ask... :)

Wanted to repeat one rational for this from a previous e-mail:

I think there are many use-cases for wanting to move beyond the boolean
"all or nothing" view of a captive portal networks. From Chicago O'Hare
airport offering free access to airline sites, to many developing-world
examples (I like to think operating system update sites should be freely
available), even 'human rights' examples in terms of access to government
resource (for FREE, in walled garden), I think UEs should be allowing users
to take advantage of these free resources...

On Wed, Apr 5, 2017 at 6:45 AM, Erik Kline <[email-masked]> wrote:

> I think it's what the majority of client OS vendors do with (first) [3]
> and (then) [2] that will determine, in a sort of game theoretic sense, how
> successful [1] will be.
>

---

From: Christian Saunders <[email-masked]>
Date: Wed, 5 Apr 2017 15:15:32 +0000

802.1x technology already exists today, but there are reasons for it not taking off in public access:

Really there are two problems that need addressing when accessing Wi-Fi:

1. Distributing 802.1x credentials - which Hotspot 2.0 makes headway towards accomplishing.

2. Network access - particularly the user experience which is what the Captive Portals exist to resolve.

I find it conceptually more elegant to consider the connectivity and access layers separately.

If we can address the access/experience problem we may be able to inform Hotspot 2.0 r3+.

Also, the access/experience/portal issue may be more widely applicable than just Wi-Fi connectivity.

Cheers!

Christian

On 17-04-05 07:04 AM, David Bird wrote:
On Tue, Apr 4, 2017 at 9:19 PM, Mikael Abrahamsson <[email-masked]<mailto:[email-masked]>> wrote:
On Tue, 4 Apr 2017, David Bird wrote:

Is there today a mechanism widely deployed in mobile devices for free use by (for instance) a hotel that just wants to make sure that someone enters their credentials (to stop passers-by to use it) and wants to view and accept the TOS *once*, and then subsequenty it's ok if you just enter same credentials each time you connect and it's fine if the user never sees the captive portal for subsequent attempts.

Yes, mechanisms exists today. It is not uncommon, for instance, for the portal to record your acceptance along with your MAC address and then do "MAC authentication" for your device for some time thereafter.

The Hotspot portal could also do a lot of things in the website itself to help with ease of use... (provided you are not using a crippled browser because of a naive captive portal detector) like remembering your state from cookies, etc, and logging you in without you noticing.

Is this available? In that case, what mechanism is that and where can I read up on it?

The mechanisms exists... and, this is very much dependent on the access policy of the venue -- not all venues will want the same thing.

802.1x technology already exists today, but there are reasons for it not taking off in public access:

- It isn't easy to use (without Hotspot 2.0) and doesn't necessarily mean you don't have a portal anymore. For instance, what does the network do when you run out of time? Just dump you off the secure wireless or give you a portal on the secure wireless?

- I'd argue it gives a FALSE sense of security to users, who are, after all, using public access with no real trust relationship with the venue or the network provider. Sure, wireless security moves the bar (a little bit) in terms of passive attacks, but doesn't protect the user from active attacks or in-line snooping off the wire. Having users see the SECURE WiFi indication on public access networks (like they see at home) is misleading. The user is better off with end-to-end security. As QUIC deploys, perhaps wireless security in public access will be less of an issue.

[Note: 802.1X can be _implemented_ in ways that still leave the user vulnerable to active attacks. For instance, with EAP-TTLS, if you don't pin the profile to a server certificate, your device can be fooled into revealing your credentials to a rogue AP.]

---

From: David Bird <[email-masked]>
Date: Wed, 5 Apr 2017 09:06:27 -0700

A few more key benefits of the ICMP approach :

- Capport detection is made easier for the client, even when RFC 7710 (or
any API) is implemented (as long as the NAS is Capport compliant).

- "Signaling" can be done by different components (NAS, iptables,
rate-limiter, PCEF, etc), without (necessarily) needing to coordinate with
a central service.

- In defining the RFC in how a NAS should handle blocking traffic for
Capport compliant devices, we are also defining how the NAS should handle
Legacy devices - which is, there is no difference - they both get ICMP Dest
Unreach w/Capport extension) - which is helpful.

---

From: David Bird <[email-masked]>
Date: Wed, 5 Apr 2017 09:25:28 -0700

Edits in-line :)

On Wed, Apr 5, 2017 at 9:06 AM, David Bird <[email-masked]> wrote:

> any API) is *NOT* implemented (as long as the NAS is Capport compliant).
>

---

From: Dave Dolson <[email-masked]>
Date: Wed, 5 Apr 2017 16:32:24 +0000

There is a risk in specifying the client check RFC7710 URL and also the Legacy HTTP query.
The risk is that portal operators will get creative in requiring work-flows involving both—must visit 7710 URL and also the redirected page.

I like the idea of specifying what the client should do.
But I also think we should label the client fall-back behavior as deprecated, to inform portal operators they should not rely on it in the future.

From: Captive-portals [mailto:[email-masked]] On Behalf Of David Bird
Sent: Wednesday, April 5, 2017 10:42 AM
To: Erik Kline
Cc: [email-masked]
Subject: Re: [Captive-portals] Arguments against (any) Capport "API"

In your example, you are doing (what I'm calling) Capport and Legacy at the same time. What would you do if Capport indicates YES (you have a portal), but Legacy says, NO (no portal)? Or wise versa? By adding Capport did we make anything easier?

After you had a success, do you ever check again (for when time expired, etc)?

Is it possible to 'suggest' that a user go to the captive portal without actually requiring it? (There are a number of use-cases here, my favorite being the offering of free low-tier rate-limited (but no captive portal) access to the Internet, but with the option of upgrading with paid access. Or, the indicating that time or data is about to run out.)

I think we tend to conflate two related, but different, issues... 1) The lack of signaling the existence of a captive portal for non-HTTP port 80 clients, and 2) issues around why OS captive portal detection fails (or is thwarted). The second issue should be addressed separately, and if that issue didn't exist, then current (OS/browser) detection methods would already be working just fine...

-  Use the network for all connections (why ask permission when forgiveness is cheap).
-  In Background, detect Capport ICMP, kick off portal notification (in real browser if https), possibly pin that (blocked) flow to an existing (LTE) network
-  In Background, Kick off Legacy HTTP query and generate a few random packets (to get Capport ICMP SessionID) - if we had rfc7710, we don't really need the Legacy HTTP result if we already see Capport ICMP, but we might compare it to the rfc7710 URL if we do get it). If Legacy is detected, but no Capport ICMP, then you have no choice but to pin all connection to LTE like you do today.
- When the Capport ICMP SessionId has changed (e.g. a Change of Authorization has occurred), go back to step 1.
- When (connection non-terminal) Capport ICMP warnings come in for flows, the user gets a 'suggestion' to go to the portal.

(A participant at the meeting indicated he was interested in pre-paid LTE use-cases, I believe those use-cases - with rfc7710 RA, at least -  are covered here as well.)

I think there are many use-cases for wanting to move beyond the boolean "all or nothing" view of a captive portal networks. From Chicago O'Hare airport offering free access to airline sites, to many developing-world examples (I like to think operating system update sites should be freely available), even 'human rights' examples in terms of access to government resource (for FREE, in walled garden), I think UEs should be allowing users to take advantage of these free resources...

On Wed, Apr 5, 2017 at 6:45 AM, Erik Kline <[email-masked]<mailto:[email-masked]>> wrote:
I think we can't get away from nodes doing both new style (7710 + yet-to-be-published stuff) and legacy detection.  In an increasingly HTTPS-ified world I would expect we'll end up with devices doing something like:

    [1]
    if (7710 available) {

    [3]
    last ditch effort here

I think it's what the majority of client OS vendors do with (first) [3] and (then) [2] that will determine, in a sort of game theoretic sense, how successful [1] will be.

If a majority of client OSes implement [3] as "never make this network the default, but some apps can use it via a multiple Provisioning Domain API (to support connecting to printer hotspots, and the like), or new TAPS API, while leaving (if available) mobile up", then captive portal vendors will at least be incentivized to stop faking out the queries that constitute [2].

If there proves to be some industry support for [1], and ongoing measurements show some meaningful adoption trends, then OS vendors can look at taking action with respect to networks that still only support [2].  This could include things like de-prioritization in ESSID auto-join algorithms.

We'll obviously need to provide value to as many reasonable parties as possible through whatever [1] ultimately becomes but that value can grow over time as functionality is added to address an increasing number of use cases.  This is definitely going to take some time.

---

From: Christian Saunders <[email-masked]>
Date: Wed, 5 Apr 2017 16:37:49 +0000

The currently proposed solution has 3 components:

1. The ICMP component is used to detect a captive network.

2. The DHCP component is used to discover the address of the Captive Portal.

3. The API is an information service with a standardized interface that allows discovery and potentially remediation of the requirements for network access.

The ICMP and DHCP components are sufficient to resolve the redirection and HTTPS issue.

I would consider the API as an optional component - it might create some user experience benefits if the device developers and network operators choose to use it.

The difficulty with the API is having a way of codifying all of the possible network access requirements.  I'm not sure this is reasonably possible.

Assuming that such a definition is possible, then there is some benefit to the common definition.

(It also strikes me that this definition would make a nice back end design for the Captive Portal itself.)

Cheers!

Christian

On 17-04-05 10:25 AM, David Bird wrote:
Edits in-line :)

On Wed, Apr 5, 2017 at 9:06 AM, David Bird <[email-masked]<mailto:[email-masked]>> wrote:
A few more key benefits of the ICMP approach :

- Capport detection is made easier for the client, even when RFC 7710 (or any API) is NOT implemented (as long as the NAS is Capport compliant).

- "Signaling" can be done by different components (NAS, iptables, rate-limiter, PCEF, etc), without (necessarily) needing to coordinate with a central service.

- In defining the RFC in how a NAS should handle blocking traffic for Capport compliant devices, we are also defining how the NAS should handle Legacy devices - which is, there is no difference - they both get ICMP Dest Unreach w/Capport extension) - which is helpful.

---

From: Dave Dolson <[email-masked]>
Date: Wed, 5 Apr 2017 16:40:17 +0000

I’d like to hear from browser vendors as to why the browser gets sandboxed when interacting with a captive portal.

If one could trust the URL came from the local network (via DHCP), could restrictions be lifted?
If the URL were HTTPS, and certificates were valid (e.g., valid cert of Chicago OHare Airport), could restrictions be lifted?

Because as we’ve heard, portals try to defeat captive portal detection to get the “real” browser: cookies, video player, etc.

-Dave

From: Captive-portals [mailto:[email-masked]] On Behalf Of David Bird
Sent: Tuesday, April 4, 2017 5:35 PM
To: Christian Saunders
Cc: [email-masked]
Subject: Re: [Captive-portals] Arguments against (any) Capport "API"

Thanks Christian,

On Tue, Apr 4, 2017 at 1:13 PM, Christian Saunders <[email-masked]<mailto:[email-masked]>> wrote:
I agree that determining the operators intention for the portal isn't really worthwhile.

This is exactly right... the (consistent) and seamless an experience as possible.

However, today this sometimes means tricking UE captive portal detection into not giving you the 'other' browser (sandboxed, incognito, or otherwise not the browser the user is already logged into sites with). For people who build fancy websites for Hotspots, you can imagine that is frustrating (to require users to login, every time, even when your site uses HTTPS and cookies are "safe").

Cheers!

Christian
Shaw Communications Inc.

David

---

From: Dave Dolson <[email-masked]>
Date: Wed, 5 Apr 2017 16:51:23 +0000

This is OK if you only need to serve devices with browsers and attentive humans.
The API offers possibilities for automation in the device by making a formal data model (vs. HTML).

From: Captive-portals [mailto:[email-masked]] On Behalf Of Christian Saunders
Sent: Wednesday, April 5, 2017 12:38 PM
To: David Bird
Cc: [email-masked]
Subject: Re: [Captive-portals] Arguments against (any) Capport "API"

Cheers!

Christian

---

From: David Bird <[email-masked]>
Date: Wed, 5 Apr 2017 10:15:32 -0700

I agree with that... but, to be clear, it really is just an improvement on
WISPr XML, and with WISPr XML already, not only used, but used to make
money, the reasons for supporting this API MUST be inline with the
venue/Operator needs. 'Automating login' (as a focus for the API) quickly
becomes venue / regional / legal / vertical / application / access policy
dependent.. Not to mention, I question the value for the user in making it
super simple for their devices to auto-login into public access networks
(without clear user intent). This seems irresponsible, on our part, when
there are solutions out there already that do automate this login, but only
after taking extra security measures (presumably, hotspot aggregators
conceal your identity when roaming, and their Apps can do more things).

On Wed, Apr 5, 2017 at 9:51 AM, Dave Dolson <[email-masked]> wrote:

> Behalf Of *Christian Saunders
> *Sent:* Wednesday, April 5, 2017 12:38 PM
> *To:* David Bird
> 3. The API is an information service with a standardized interface that
> allows discovery and potentially remediation of the requirements for
> network access.
>
> I would consider the API as an optional component - it might create some
> user experience benefits if the device developers and network operators
> choose to use it.
>
> The difficulty with the API is having a way of codifying all of the
> possible network access requirements.  I'm not sure this is reasonably
> possible.
>

---

From: Christian Saunders <[email-masked]>
Date: Wed, 5 Apr 2017 17:23:12 +0000

Good point.

Maybe for an operator this bumps the API to a 'SHOULD'.

In a lot of cases a limited IoT device will be incapable of satisfying the requirements.

What I would like here is some means of delegating the authorization process off to another device that would have a more capable interface.  Do we need to add a spec for this?

Cheers,

Christian

On 17-04-05 10:51 AM, Dave Dolson wrote:
This is OK if you only need to serve devices with browsers and attentive humans.
The API offers possibilities for automation in the device by making a formal data model (vs. HTML).

Cheers!

Christian

---

From: Christian Saunders <[email-masked]>
Date: Wed, 5 Apr 2017 17:30:16 +0000

Does WISPr support all of the use cases?  Is there a publicly available source for the WISPr XML spec?

Cheers!

Christian

On 17-04-05 11:15 AM, David Bird wrote:
I agree with that... but, to be clear, it really is just an improvement on WISPr XML, and with WISPr XML already, not only used, but used to make money, the reasons for supporting this API MUST be inline with the venue/Operator needs. 'Automating login' (as a focus for the API) quickly becomes venue / regional / legal / vertical / application / access policy dependent.. Not to mention, I question the value for the user in making it super simple for their devices to auto-login into public access networks (without clear user intent). This seems irresponsible, on our part, when there are solutions out there already that do automate this login, but only after taking extra security measures (presumably, hotspot aggregators conceal your identity when roaming, and their Apps can do more things).

On Wed, Apr 5, 2017 at 9:51 AM, Dave Dolson <[email-masked]<mailto:[email-masked]>> wrote:
This is OK if you only need to serve devices with browsers and attentive humans.
The API offers possibilities for automation in the device by making a formal data model (vs. HTML).

From: Captive-portals [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Christian Saunders
Sent: Wednesday, April 5, 2017 12:38 PM
To: David Bird
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [Captive-portals] Arguments against (any) Capport "API"

Cheers!

Christian

---

From: David Bird <[email-masked]>
Date: Wed, 5 Apr 2017 10:45:32 -0700

There are problems with WISPr, one being that it has somewhat ambiguous
copyrights, which is why you will not find it easily on-line.

It was proposed by WFA, but never ratified. With that said, there are some
lessons to be learned from it:

- It probably would be good to have something with cleaner specifications,
but adoption by the long-tail hotspot operators could be slow (even slower
thank upgrading NAS capabilities). Critical to vendor/venue adaption will
be roaming aggregator adoption, and you have the chick and egg problem.

- WISPr XML wasn't overly complicated, but it being implemented by all
sorts of portals, in all sorts of ways, gave it a very bad reputation as
being broken. (A fear I have for our API as well.)

- WISPr only defined, basically, a Username / Password login method, which
fits AAA/RADIUS models, and the industry has largely adapted to (for
instance, it is common to do 'Mac Auth' using a shared 'Password' field or
to fit voucher codes into a username/password combinations).

---

From: Christian Saunders <[email-masked]>
Date: Wed, 5 Apr 2017 17:58:29 +0000

I was just refreshing my memory on the WISPr spec and I agree with all of your points.

  I would add that WISPr is a very rigid protocol with a very specific flow and intention.

  Because of these shortcomings, I would leave the option of an API on the table - particularly with a nod to the lessons that we can learn from WISPr and it's implementations.

Cheers!

Christian

On 17-04-05 11:45 AM, David Bird wrote:
There are problems with WISPr, one being that it has somewhat ambiguous copyrights, which is why you will not find it easily on-line.

It was proposed by WFA, but never ratified. With that said, there are some lessons to be learned from it:

- It probably would be good to have something with cleaner specifications, but adoption by the long-tail hotspot operators could be slow (even slower thank upgrading NAS capabilities). Critical to vendor/venue adaption will be roaming aggregator adoption, and you have the chick and egg problem.

- WISPr XML wasn't overly complicated, but it being implemented by all sorts of portals, in all sorts of ways, gave it a very bad reputation as being broken. (A fear I have for our API as well.)

- WISPr only defined, basically, a Username / Password login method, which fits AAA/RADIUS models, and the industry has largely adapted to (for instance, it is common to do 'Mac Auth' using a shared 'Password' field or to fit voucher codes into a username/password combinations).

On Wed, Apr 5, 2017 at 10:30 AM, Christian Saunders <[email-masked]<mailto:[email-masked]>> wrote:
Does WISPr support all of the use cases?  Is there a publicly available source for the WISPr XML spec?

Cheers!

Christian

Cheers!

Christian

---

From: <[email-masked]>
Date: Wed, 5 Apr 2017 18:17:51 +0000

Hey,

One real benefit of the API could be that  there is no need to load the whole portal.
To have WISPr working you will download (mostly) the HTML of the Portal. This gives you often on crowded networks a kind of this broken experience that David describes.

Also the implementation of the WISPr Clients is a bit of pain, as there is no “real standard” as explained before. So it could also decrease dev costs significant.

Cheers,
Sascha

Von: Captive-portals [mailto:[email-masked]] Im Auftrag von Christian Saunders
Gesendet: Mittwoch, 5. April 2017 19:58
An: David Bird
Cc: [email-masked]
Betreff: Re: [Captive-portals] Arguments against (any) Capport "API"

Cheers!

Christian

Cheers!

Christian

Cheers!

Christian

---

From: David Bird <[email-masked]>
Date: Wed, 5 Apr 2017 11:28:49 -0700

Agreed. There is real value in replacing WISPr with something standards
based, that aims to only improve on the "API", without trying to stuff
everything into it. However, that doesn't mean it will be deployed, or
deployed well.

Yes, part of the problem with WISPr XML is that is can be put in multiple
places, including embedded in the actual portal website (as HTML comments).
In that case, yes, the client has to follow the redirect and parse through
an HTML page for the XML block, which is crappy.

However, most hotspots these days do put the XML in the initial redirect,
which a client could pick up without much issue.. e.g.

GET /generate_204 HTTP/1.1
Host: captive-portal-check.appspot.com
Connection: keep-alive
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_3)
AppleWebKit/537.36 (KHTML, like Gecko) Chrome/56.0.2924.87 Safari/537.36
Accept: */*
Accept-Encoding: gzip, deflate, sdch
Accept-Language: en-US,en;q=0.8

HTTP/1.1 302 Found
Location: https://via.boingohotspot.net/login
Connection: close
Content-Type: text/html; charset=utf-8
Content-Length: 343

<!--<?xml version="1.0" encoding="UTF-8"?><WISPAccessGatewayParam
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:noNamespaceSchemaLocation="http://www.acmewisp.com/
WISPAccessGatewayParam.xsd"><Redirect><LoginURL>https://
via.boingohotspot.net/login</LoginURL><MessageType>100</
MessageType></Redirect></WISPAccessGatewayParam>-->

On Wed, Apr 5, 2017 at 11:17 AM, <[email-masked]> wrote:

> To have WISPr working you will download (mostly) the HTML of the Portal.
> This gives you often on crowded networks a kind of this broken experience
> that David describes.
>
>
>
> Also the implementation of the WISPr Clients is a bit of pain, as there is
> no “real standard” as explained before. So it could also decrease dev costs
> significant.
>
>
>
> Cheers,
>
> Sascha
>
>
>
>
>
> *Von:* Captive-portals [mailto:[email-masked]] *Im
> Auftrag von *Christian Saunders
> *Gesendet:* Mittwoch, 5. April 2017 19:58
> *An:* David Bird
> *Betreff:* Re: [Captive-portals] Arguments against (any) Capport "API"
>
>
>
>   Because of these shortcomings, I would leave the option of an API on the
> table - particularly with a nod to the lessons that we can learn from WISPr
> and it's implementations.
>
> Cheers!
>
> Christian
>

---

From: Vincent van Dam <[email-masked]>
Date: Wed, 5 Apr 2017 19:25:15 +0000

I don’t think the API should contain anything that would move control towards the UE. I think the API at most should be informative; as a decoration on the information it could provide the user by either sending him to the capport url, or as additional information that was not included in the icmp message that triggered the API call. Authentication of the icmp message could also be a role for the API, but I think if this could be solved without the API but with icmp itself, it would be much better.

I expect if the API would be rich, and hint towards control, adoptation will be low, and could lead to half/buggy implemetations. Also, I expect, if the capport provider is trying to defeat the sandboxed browsers, which seems to be because they lack control (analytics/tracking/marketing requirements), I think it’s safe to assume that an API that potentially can go beyond the sandboxed browser limitations, would not be something commercial capport providers would appreciate.

Also, I have my doubts concerning legal issues as well; for e.g. accepting t&c’s, would the capport-provider rely on a UE implementation that would display & handle accepting this? What if there is a legal dispute, and the question arises if the user actually accepted the t&c’s; where would you start the investigation and the capport or at the UE implementation that did some magic t&c accepting implementation? Moving (or keeping) that journey inside a browser would leave the control at the capport-side.

With that in mind, and back to my first statement, I think the only decoration that makes sense is too facilitate devices that aren’t capable of displaying the capport itself, but maybe are capable of displaying some message on a small display (internet of things, maybe e.g. a internet radio appliance). But maybe this could be solved by supplying a reason in the icmp.

The sandboxed browser is something interesting. If the icmp would trigger, instead of the capport detection, and the result would be that the capport sandboxed browser is opened; how would that fit the (e.g. mobile) use case where the user hit is quota when he was watching youtube. Most of the discussions focus on joining the network, while in my opinion this is just one half of the capport scope.

The ohare airport is interesting as well; if the icmp is the trigger, the capport might not be triggered immediately. I can imagine, they would like to inform the user upfront of what they provide; not wait until the UE visits something outside of the walled garden.

Would it make sense to hint the UE that the capport should not be opened in the sandbox browser, but should be opened in the default browser instead? Currently there is no formal means for the capport provider, other than give the correct responses on the magic urls. Though, I think if this option would exist, by default capport providers will choose to use the regular browser.

________________________________
Van: Captive-portals [[email-masked]] namens David Bird [[email-masked]]
Verzonden: woensdag 5 april 2017 19:15
Aan: Dave Dolson
CC: [email-masked]; Christian Saunders
Onderwerp: Re: [Captive-portals] Arguments against (any) Capport "API"

Cheers!

Christian

---

From: David Bird <[email-masked]>
Date: Wed, 5 Apr 2017 13:02:23 -0700

Thanks for your comments!

Re: "I can imagine, they would like to inform the user upfront of what they
provide; not wait until the UE visits something outside of the walled
garden."

I agree, but chances are VERY high that _something_ will trigger the Os
capport detection to give the user a captive portal notification. If not,
then the walled garden is so large that the UE (nor the user) should even
care if there is a portal or not. (The user might like the fact that their
phone is already doing software upgrades, maybe at a low rate limit, in the
walled garden even while they are interacting with the captive portal).

I think the UE is foolish to take any such information from the API ... I
am already writing my blog post entitled "How IETF standards are keeping
your devices captive" :)

On Wed, Apr 5, 2017 at 12:25 PM, Vincent van Dam <[email-masked]>
wrote:

> I don’t think the API should contain anything that would move control
> towards the UE. I think the API at most should be informative; as a
> decoration on the information it could provide the user by either sending
> him to the capport url, or as additional information that was not included
> in the icmp message that triggered the API call. Authentication of the icmp
> message could also be a role for the API, but I think if this could be
> solved without the API but with icmp itself, it would be much better.
>
>
> I expect if the API would be rich, and hint towards control, adoptation
> will be low, and could lead to half/buggy implemetations. Also, I expect,
> if the capport provider is trying to defeat the sandboxed browsers, which
> seems to be because they lack control (analytics/tracking/marketing
> requirements), I think it’s safe to assume that an API that potentially can
> go beyond the sandboxed browser limitations, would not be something
> commercial capport providers would appreciate.
>
>
> Also, I have my doubts concerning legal issues as well; for e.g. accepting
> t&c’s, would the capport-provider rely on a UE implementation that would
> display & handle accepting this? What if there is a legal dispute, and the
> question arises if the user actually accepted the t&c’s; where would you
> start the investigation and the capport or at the UE implementation that
> did some magic t&c accepting implementation? Moving (or keeping) that
> journey inside a browser would leave the control at the capport-side.
>
>
> With that in mind, and back to my first statement, I think the only
> decoration that makes sense is too facilitate devices that aren’t capable
> of displaying the capport itself, but maybe are capable of displaying some
> message on a small display (internet of things, maybe e.g. a internet radio
> appliance). But maybe this could be solved by supplying a reason in the
> icmp.
>
>
> The sandboxed browser is something interesting. If the icmp would trigger,
> instead of the capport detection, and the result would be that the capport
> sandboxed browser is opened; how would that fit the (e.g. mobile) use case
> where the user hit is quota when he was watching youtube. Most of the
> discussions focus on joining the network, while in my opinion this is just
> one half of the capport scope.
>
>
> The ohare airport is interesting as well; if the icmp is the trigger, the
> capport might not be triggered immediately. I can imagine, they would like
> to inform the user upfront of what they provide; not wait until the UE
> visits something outside of the walled garden.
>
>
> Would it make sense to hint the UE that the capport should not be opened
> in the sandbox browser, but should be opened in the default browser
> instead? Currently there is no formal means for the capport provider, other
> than give the correct responses on the magic urls. Though, I think if this
> option would exist, by default capport providers will choose to use the
> regular browser.
>
>
> ------------------------------
> *Van:* Captive-portals [[email-masked]] namens David
> Bird [[email-masked]]
> *Verzonden:* woensdag 5 april 2017 19:15
> *Aan:* Dave Dolson
> *CC:* [email-masked]; Christian Saunders
> *Onderwerp:* Re: [Captive-portals] Arguments against (any) Capport "API"
>

---

From: David Bird <[email-masked]>
Date: Wed, 5 Apr 2017 14:37:53 -0700

The browser sandboxing issue is slightly more complex... I too am hoping
engineers working on such things participate in this discussion!

I've been told various reasons, from 'I don't remember', to 'others do it
that way', and sometimes reasons why it serves to protect the user. The
latter argument, I believe, is historic in that captive portal networks
were (are?) viewed as 'hostile'. I don't think this argument really holds
much weight because:

- It conflates captive portal to mean public access. Today, a captive
portal doesn't have to mean public access (it can be a trusted network
too). Also, an Open SSID network with no portal is just as hostile (if not
more, in that they aren't even notifying you of their man-in-the-middle
'presence').

- The sandbox browser comes up because, we guess, the network is 'hostile'
(even though the user *selected* this SSID in the case of it being Open),
yet after the user interacts with the captive portal, the UE determines all
the sudden that the network is not so hostile? To think that people today
select an Open SSIDs and then freak out about a captive portal I think is
out-dated.

If protecting the user, while also offering ease of use for legitimate
captive portals, I will be idealistic and say:

- UE should classify networks as public vs. private, where an Open SSID is
always automatically put into the public category. All non-secure browser
connections get sandboxed, secure connections go ahead (let TLS do its
thing). [This line item has nothing to do with captive portals.]

- If the UE detects capport, that it will at least check the URL from
capport detection (following any redirects) to verify it is https:// before
launching a user default browser (with or without a message somewhere
indicating this site is a captive portal).  If it makes the user feel
better, non-https could be sandboxed, but not when secured.

- To prevent a network from getting a URL / website into your default
browser cache (by hijacking and redirecting you there), the UE should
present the user (even in the notification event) of the captive portal URL
FQDN they are about to connect to -- it could even give a TLS indication
and cert verification icon. (Of course, the clever attacker can still mess
with you using DNS and hijacking connections later on, after capport
detection, so...)

What is ironic is that this is sometimes called an 'arms race', when in
fact both parties are just trying to make the user experience better or
safer, yet neither are being successful. For Hotspots, they have website
usability reasons to hate capport detection, yet increasingly they are
having problems with user experiences around HTTPS. Engineers hate captive
portal, they think they are *broken*, and think avoiding detection is
further proof captive portals can't be trusted. Hotspot are largely broken
for the user because of the combination of sandboxed browsers and OS
capport detection being evaded.

A note about capport detection evasion: It is not always on purpose... As
more hotspots do "social login" applications, they are opening up the
walled garden surprisingly wide to get that to work...

On Wed, Apr 5, 2017 at 9:40 AM, Dave Dolson <[email-masked]> wrote:

> If the URL were HTTPS, and certificates were valid (e.g., valid cert of
> Chicago OHare Airport), could restrictions be lifted?
>
>
>
> Because as we’ve heard, portals try to defeat captive portal detection to
> get the “real” browser: cookies, video player, etc.
>
>
>
> -Dave
>
>
>
>
>
> *Sent:* Tuesday, April 4, 2017 5:35 PM
> *To:* Christian Saunders
>
> *On the other hand, it is worth providing the operators with tools to

---

From: Michael Richardson <[email-masked]>
Date: Thu, 06 Apr 2017 11:05:55 -0400

David Bird <[email-masked]> wrote:
    > capport detection to give the user a captive portal notification.  If
    > not, then the walled garden is so large that the UE (nor the user)

Only if the user hasn't got another network connection.

There may be many possible (wifi) networks available, and being able to ask
each what they provide without leaking any other http traffic or DNS requests
seems like a good thing to me.

I haven't found the point in the thread where the arguments against were
clearly stated. Feel free to unicast me a pointer to the right part of
the archives.

---

From: Michael Richardson <[email-masked]>
Date: Thu, 06 Apr 2017 11:13:48 -0400

Dave Dolson <[email-masked]> wrote:
    > I’d like to hear from browser vendors as to why the browser gets
    > sandboxed when interacting with a captive portal.

Security in layers.
The browser contains lots of interesting cookies and other state.

A captive portal could, for instance, provide a stack of img URLs to places
where the user might have cookies, and the browser may reach out to try
to load things.  Even if those URLs are HTTPS and the captive portal lets
them through, just observing the size of the packets would tell the
portal operator whether or not the user has a relationship to that
entity.  Of course, if they put http URLs in then snooping is obvious.

(The operator can, of course, do this anyway, but the user does have a
point where they can, for instance, bring up a VPN to protect all their
traffic.  My Android phone now apparently does this for me automatically when
I'm on high-quality public WiFI.  More cool is that it appears to use IPv6 on
the inside.  More funny was that google then alerted me to suspicious
activity from an IPv6 I'd never before logged into... which was the inner
tunnel IP...)

    > could restrictions be lifted?

I don't think this matters at all.

    > Chicago OHare Airport), could restrictions be lifted?

I don't think so.  I'm also unclear how the end-user can be sure that the
certificate in question is really from the location they are in.  In many
cases, it's not "chicago-ord.com", but rather, "ord.boingo.com"...

---

From: Michael Richardson <[email-masked]>
Date: Thu, 06 Apr 2017 11:20:26 -0400

David Bird <[email-masked]> wrote:
    > A note about capport detection evasion: It is not always on purpose...
    > As more hotspots do "social login" applications, they are opening up
    > the walled garden surprisingly wide to get that to work...

I think that within the Android ecosystem (which I know a lot about), that it
should be possible to form an intent from the captive browser to the system
to invoke the appropriate app and return an OAUTH2 token.  This doesn't have
to happen within JS from within the captive browser.  I imagine that iOS
ecosystem can handle something similar, but I believe that it hasn't (yet?) got
Intents that are as flexible.

On a desktop system there are fewer options, but given dbus, and
OSX/microsoft equivalents, I don't see why it couldn't happen.
The "gcalapi" python script nicely asks my browser for an oauth token today.

---

From: David Bird <[email-masked]>
Date: Thu, 6 Apr 2017 08:34:42 -0700

> seems like a good thing to me.
a) You are already leaking information (DHCP, etc) as you need IP
connectivity before you do anything (unlike Hotspot 2.0 where you are in
fact querying networks prior to association). In the case of Open WiFi, you
also already had user intent to join the network. If you are talking about
auto-login scenarios and leaking information, I'd argue that has nothing to
do with "captive portals" and more to do with "public access" ... and
auto-login into public access is pretty much always a bad idea (unless
further security is being provided).

b) You will happily leak all this information when there IS NOT a captive
portal... How did the portal increase your exposure? The portal, in some
respects, is doing you a favor.

> clearly stated. Feel free to unicast me a pointer to the right part of
a) There really is no incentive for any venue/operator to deploy the API
(if there is an incentive, it isn't to the benefit of the user, see below)

b) If 'discovery' (e.g. knowing what is in walled garden, etc) is through
an API, you will have hotspots that keep Capport device 'captive' when the
network might not really enforce it. I think you just gave the operator WAY
too much control over the Capport compliant device. Not to mention, it
would be embarrassing that you will have hotspots that keep
"Capport compliance" devices captive, where legacy devices are not.

c) There is highly likely that you will have broken implementation (e.g. an
API and a DHCP server support Capport, but without any real NAS) - this
could be intentional or completely by mistake. You can imagine it would be
pretty easy to mistakenly configure a DHCP server with a "Captive Portal
URL", pointing it to some hotspot provider company, and presto - you have a
Capport device only hotspot (that doesn't actually work).

d) There will be such huge problems in deployment that UEs will just ignore
this Capport API, still rely on Legacy discovery, and nothing has changed
(in fact, it only got more complicated and broken).

---

From: David Bird <[email-masked]>
Date: Thu, 6 Apr 2017 10:55:14 -0700

I found a really good example of why a Hotspot operator would not want to
share their walled garden configuration with visitors (unless they have to,
e.g. you try to access the service). Or, at least a reason for them to NOT
give you the full picture (e.g. lie).

I stumbled onto a configuration file, that I don't think was meant to be
publicly available (so, I will not provide a link). It is the NAS walled
garden configuration for several airports for a major hotspot services
company. It reveals a lot about their partners and business model. I don't
see why a venue would want to advertise this information, accurately
anyway....

On Wed, Apr 5, 2017 at 1:02 PM, David Bird <[email-masked]> wrote:

> Re: "I can imagine, they would like to inform the user upfront of what
> they provide; not wait until the UE visits something outside of the walled
> garden."
>
>> Also, I have my doubts concerning legal issues as well; for e.g.
>> accepting t&c’s, would the capport-provider rely on a UE implementation
>> that would display & handle accepting this? What if there is a legal
>> dispute, and the question arises if the user actually accepted the t&c’s;
>> where would you start the investigation and the capport or at the UE
>> implementation that did some magic t&c accepting implementation? Moving (or
>> keeping) that journey inside a browser would leave the control at the
>> capport-side.
>>
>>
>> The sandboxed browser is something interesting. If the icmp would
>> trigger, instead of the capport detection, and the result would be that the
>> capport sandboxed browser is opened; how would that fit the (e.g. mobile)
>> use case where the user hit is quota when he was watching youtube. Most of
>> the discussions focus on joining the network, while in my opinion this is
>> just one half of the capport scope.
>>
>>
>> I agree with that... but, to be clear, it really is just an improvement
>> on WISPr XML, and with WISPr XML already, not only used, but used to make
>>> - Capport detection is made easier for the client, even when RFC 7710
>>> (or any API) is *NOT* implemented (as long as the NAS is Capport
>>> compliant).
>>>
>>>
>>>

---

From: David Bird <[email-masked]>
Date: Thu, 6 Apr 2017 17:44:20 -0700

> entity.  Of course, if they put http URLs in then snooping is obvious.
This is normal browser security stuff (a non-http page can't load content
from https sites without an error) and threats when on untrusted networks
of any kind, particularly Open SSIDs with NO portal.

> activity from an IPv6 I'd never before logged into... which was the inner
Android did this because you were at high quality public access network, it
will do the same thing for Open WiFi w/o capport. (I hope that is right,
I'm pretty sure... :)

> cases, it's not "chicago-ord.com", but rather, "ord.boingo.com"...
Would visitors know the difference, which is more legitimate?  As a
traveler, you might prefer/trust the more familiar "boingo.com" in the
FQDN. In this case, I think ORD and Boingo probably do joint marketing
anyway...  This sort of detail becomes a win-win-win in that the user gets
to see what website (and server cert status) they are about to go to (equal
to, if not safer, than when relatives send them hyperlinks in e-mails), the
vendor sells NAS upgrades, operator gets to sell venues the ability to
brand their WiFi, and the venue gets the chance for branding in the captive
portal detection notification - all (reputable) parties motivated to
support the feature... this 'feature' would deploy quickly, imho, if
clients supported it (complete with the 'suggested' captive portal
notification, not just when required) as it adds new ways of selling and
connecting with the user. And, it could be done in a rather un-intrusive
way, that is benefiting the user (who wants to stay connected) as much as
the venue.

[ In this fantasy, 'feature' means IETF standards plus a client side change
to how captive portals are handled. That last part, when it includes things
like how to display user notifications and such, I don't think is the usual
role of IETF... that is more WFA (similar to Hotspot 2.0 OSU). Is it
possible that IETF can't solve this problem entirely? What is the 'carrot'
for the client vendors? ]

---

From: Martin Thomson <[email-masked]>
Date: Fri, 7 Apr 2017 13:46:53 +1000

On 7 April 2017 at 10:44, David Bird <[email-masked]> wrote:
> the more familiar "boingo.com" in the FQDN

You mean boıngo.com ?  Looks legit.

On the larger subject, as a browser person, the real reason for
sandboxing is - I believe - privacy.  One basic security assumption
for the web is that it is easy to cause a user to visit a site.  A
captive portal isn't special in that regard, so I don't credit claims
that sandboxing is a security measure.

The credible reason is that you don't want a user to be tracked (or
de-anonymized) across points of network connection.  That is
definitely a credible story.  You don't want the network using cookies
set by a portal in network A being read by a portal at the same origin
in network B when you just took somewhat extraordinary steps to ensure
that your MAC address was different in both networks.

That doesn't sound like much.  And it is trivially defeated (see
below).  The same user likely visits the same websites from both
locations, but the captive portal has a unique ability to correlate
network-level information (e.g., MAC) with persistent state.  Random
sites on the internet don't have the same access.

The way to defeat this is to wait for an unencrypted HTTP session to
pass.  You can observe tracking cookies and use them to de-anonymize
users. If there are no tracking cookies, then "header encrichment" can
be used to implant a cookie.  We learned at the last meeting that this
is one reason that portals defeat detection: so they can fall back on
this technique.

If the entire web were to use HTTPS exclusively, this method might
stop working.  Or users would have to restrict their cleartext
browsing to a sandbox.  (We've discussed shorter cookie lifetimes for
cleartext origins on the web, but the usability concerns are basically
insurmountable right now.)

---

From: David Bird <[email-masked]>
Date: Thu, 6 Apr 2017 21:35:39 -0700

On Apr 6, 2017 8:46 PM, "Martin Thomson" <[email-masked]> wrote:

Yes, that (all the privacy and security  risks) is true with public access,
generally. (Why are captive portal networks extra suspicious?) Browsers
themselves might behave differently on a 'capport compliant' device in that
they would rely on the os detection. But, the browser could (and can today)
simply ask the user 'want to connect to this captive portal?' .. let the
user decide. It is pretty safe if https and a URL the user is comfortable
with.

this technique

I agree, these are all issues with public access, generally. As far as
defeating detection because they *want* the users background traffic,
well.. they sorta have a point: they could be offering access with no
portal and the user (or apps) wouldn't​ be the wiser. One benefit about the
ICMP method is that defeating detection isn't possible - iff the Nas
complies with rfc and responds appropriately to blocked traffic, with or
without rfc7710 support.

Applications that use cleartext protocols in the background on public
access networks should stop doing that! The OS should have a 'public access
mode' that stops cleartext apps from working (to make app developers learn
the hard way)... It is more of a judgement call if the user wants to use
secure connections on public access networks, but they did select the SSID,
I think their intention to use the network, if they can, is clear.

Absolutely, browsers should take measures to help users not use clear-text
protocols on *any* public access network.

I think it is also true that browsers (and os) shouldn't care about, and
shouldn't prevent users from accessing, secured resources freely available
on public access networks, without captive portal (which they do today), or
within the captive portal walled garden (not always true today).

---

From: Vincent van Dam <[email-masked]>
Date: Fri, 7 Apr 2017 08:40:21 +0000

Yes, that (all the privacy and security  risks) is true with public access, generally. (Why are captive portal networks extra suspicious?) Browsers themselves might behave differently on a 'capport compliant' device in that they would rely on the os detection. But, the browser could (and can today) simply ask the user 'want to connect to this captive portal?' .. let the user decide. It is pretty safe if https and a URL the user is comfortable with.

I agree with asking the user. Both capport and UE are making a decision to either display or not display in a sandboxed browser. They take this decision on behalf of the user and I think this evolved like this. Doing one step back, imo it makes more sense to (once the icmp is received) display a dialog and ask how the user wants to continue to the capport (if UE permits). UE can optimise this user flow by either choosing a default behaviour they see fit and have the user configure this behaviour somewhere, or just remember what the user had chosen. If the UE would send an extra http-header indicating the capport is visited in the sandboxed browser, the capport can inform the user if they think it would be better to fulfil the journey in a regular browser (and explain how to do that). Either way, the user will be in control, rather than either capport or UE.

Gr.,
Vincent van Dam

---

From: Martin J. Dürst <[email-masked]>
Date: Fri, 7 Apr 2017 18:42:58 +0900

> You mean boıngo.com ?  Looks legit.

Turkish users will spot the problem easily :-).

Regards,   Martin.

---

From: David Bird <[email-masked]>
Date: Fri, 7 Apr 2017 05:08:04 -0700

Indeed :)

To be clear, Gmail hyperlinked boingo.com for me... but, the point is that
the UE/capport detection parsed and validated (checked the cert and cert
status) of the FQDN. It is not some URL with questionable formatting...

---

From: Erik Kline <[email-masked]>
Date: Fri, 7 Apr 2017 22:36:15 +0900

> -  Use the network for all connections (why ask permission when

Not gonna happen.  Mobile clients do a ton of work to enable "make before
break".  There is no such thing as forgiveness from users who can't get
Facebook updates, Twitter notifications, nor email while their device is
held hostage because it switched to Wi-Fi and tore down mobile before
checking for a captive portal.

This may also address your question elsewhere about browsers and
"sandboxing".  I suspect the sandboxing to which you're referring is about
cookie isolation (primarily), but there's a kind of "network sanboxing"
that is applied as well to ensure the browser uses a self-consistent
networking configuration.

---

From: David Bird <[email-masked]>
Date: Fri, 7 Apr 2017 06:52:55 -0700

> checking for a captive portal.
But, it DOES happen when you connect to Open SSID without captive portal
(or when the venue evaded your detection). Maybe the captive portal
networks wants to offer these services in their walled garden... and it is
likely the user would be happy about that (provided they selected the
network on purpose).

If you had ICMP giving you real-time feedback, you could more accurately
(and quickly) detect what connections will work and which will not on the
network. QUIC will help in maintaining session continuity as connections
are pinned to different interfaces.

> networking configuration.

Cookie isolation on secure websites doesn't really help the user any...

---

From: David Bird <[email-masked]>
Date: Fri, 7 Apr 2017 08:03:12 -0700

A root cause of the so-called 'arms race' around captive portal detection
that I'm trying to highlight is that it will always continue for as long as
UEs treat captive portal networks specifically different than they do
public access networks generally, you will have incentive to exploit that
difference in behavior in the public access industry.

---

From: Erik Kline <[email-masked]>
Date: Sat, 8 Apr 2017 01:11:36 +0900

I fundamentally do not understand what it is you're trying to say here.  I
apologize for being thick.

The mobile devices with which I am most familiar do "make before break"
even for unsecured SSIDs without a captive portal.  They do a few probes of
various types and to various destinations (vis. Mariko's research and
presentation) on /every/ network before deciding whether to switch general
traffic over to it.

(Note that a few apps that style themselves as networking sophisticates may
try to fling a few packets on a newly attached network before the OS has
done its validation, but those are the very rare exception.  And we see the
occasional bug report when they get themselves confused because they
haven't waited for the system's detection to do its thing or haven't
trusted the detection result.  =)

I don't understand how these mobile devices should be doing something
different.  Failing to do what they currently do and going back to "break
before make" will not sit well with users.  I personally do not see a
solution down that road, but perhaps I misunderstand or others see
something I don't yet.

On 8 April 2017 at 00:03, David Bird <[email-masked]> wrote:

>>> Not gonna happen.  Mobile clients do a ton of work to enable "make
>>> before break".  There is no such thing as forgiveness from users who can't
>>> get Facebook updates, Twitter notifications, nor email while their device
>>> is held hostage because it switched to Wi-Fi and tore down mobile before

---

From: David Bird <[email-masked]>
Date: Fri, 7 Apr 2017 12:01:35 -0700

I am not claiming to have all the answers, or that this is an easy (or a
single) problem to solve.  And I reserve the right to be completely wrong :)

Absolutely, as a mobile subscriber with unlimited data who (more or less)
trusts my mobile provider, it is also my preference that devices behave as
they do today (except when I do interact with 'legitimate' portals, they
are often broken or extra annoying because of the browser selection, I
sometimes turn off WiFi). I think there are other use-cases and other users
have different priorities, trust in network providers, and data plans.

What I think you are illustrating is that it is technically VERY
challenging to implement "make before break" for an entire network for all
connections in environments that only provide limited access to a limited
number of connections (and that it is particularly hard to do this in
'hostile' public access networks where there are commercial incentives for
trickery). There are very different cost, benefit, and trust considerations
for users. Hopefully, new protocols like QUIC and Capport can make that
hand-off smoother, robust, and secure while also allowing users access to
resources in public access environments (with or without captive portal and
walled garden).

When I talk about 'public access', I include all Open SSIDs with and
without portal, and even some wired environments. As a venue/provider,
those are my option when offering public access: a) Wide Open SSID, no
portal, few customer complains (and those all get directed to vendors, UE ,
AP, or ISP), maybe legal issues, probably have squatters hogging bandwidth,
b) Open SSID with captive portal, more complaints (which is an ongoing
issue that can't as easily dumped onto vendors), but also making money and
have branding and analytics to offset the costs of providing public access,
fewer problems with squatters, c) do a combination of things, including
wired. I talk about 'public access industry' in terms of NASDAQ and private
companies that represent an ecosystem where commercial marketing often
centers on making it *Easy* and *Secure* to get public access around the
world...

When I talk about the difference in behavior UEs have for 'public access'
and 'captive portal', I think some pockets of engineers, who have
responsibility for the security of their specific users, understand this
difference in that you want to protect the user just as much on Open WiFi
networks irrespective of the existence of a captive portal (i.e. any public
access). I think some UE engineers also feel uncomfortable about supporting
Open WiFi at all (and therefore give users warnings), but users demand it
-- why? because of public access and ease-of-use. Today most people
consider an Open SSID to indicate 'public access'. That SSID may or may not
have a portal, full or partial Internet access, or all sorts of
man-in-the-middle "applications". Figuring out what trickery is happening
in public access networks will always be a moving target...

What I believe is that public access network providers who use captive
portal feel completely *justified* in doing anything they could otherwise
do when users connect to an Open SSID (without captive portal) public
access networks. After all, the user trusts the UE, and the UE trusts the
user intent to join the Open SSID public access network after it warned the
user about the risks. If UE vendors want to change that behavior, I think
it is as easy as enforcing the same policy for Open SSID w/o portal as with
portal (i.e. a common policy for all public access). There would no longer
be incentive to trick UE captive portal detection, because the public
access network is being treated the same by the UE regardless. However,
this will shift user complaints about public access non-usability, even for
Open SSID networks with no portal, to the vendors instead of the network
operator. There is a delicate balance there between what users want, what
they *should* want, what they are willing to give up, and what services
networks are trying to provide. Venues get all those usability complaints
today, and the solutions they come up with are not often elegant.

As I said, not an easy, or single, problem... And one we can't completely
solve (or even try to) in this WG. However, there are things we can do to
improve capport nonetheless.

On Fri, Apr 7, 2017 at 9:11 AM, Erik Kline <[email-masked]> wrote:

> (Note that a few apps that style themselves as networking sophisticates
> may try to fling a few packets on a newly attached network before the OS
> has done its validation, but those are the very rare exception.  And we see
> the occasional bug report when they get themselves confused because they

---

From: Michael Richardson <[email-masked]>
Date: Fri, 07 Apr 2017 15:54:31 -0400

David Bird <[email-masked]> wrote:
    > portal (or when the venue evaded your detection). Maybe the captive
    > portal networks wants to offer these services in their walled
    > garden... and it is likely the user would be happy about that
    > (provided they selected the network on purpose).

Consider a school that uses Google Apps (like my sons').

They run a somewhat loose firewall that blacklists stuff; but probably would
be better off to whitelist things.

The ICMP reply could very well be used to trigger the teacher override.

---

From: David Bird <[email-masked]>
Date: Fri, 7 Apr 2017 14:48:05 -0700

I could probably explain myself another way, but first I will say that
"make before break" obviously makes a ton of technical sense, hence why
most vendors do it. And, I'm speaking generally, I'm sure different vendors
are doing slightly different things. But, I think the 'arms race' is proof
that it has some consequences that either operators find annoying, or
reports we are hearing are just 'fake news' :)

Another way to view it...

Consider the ideal user experience:
User: Wanting Wi-Fi, and already knows about years of reports about how
un-safe public WiFi is.
UE: Hey, btw, there is public access WiFi available
User: Click, yay! (Just like the IETF network!) [Everything works]
WISP: Wow, that is a ton of valuable data, but we lack control

Now consider the ideal user experience from the WISP perspective:
User: Wanting Wi-Fi, and already knows about years of reports about how
un-safe public WiFi is.
UE: Hey, btw, there is public access WiFi available
User: Click, yay! (Just like the IETF network!, oh, wait, there is a
portal) [Some apps fail (though UE could then pin to LTE), others may work
in walled garden (if the UE allows them)]
WISP: Nice... still getting a ton of valuable data, and we have some user
contact, consent, branding, and service selling opportunists!
User: A bit annoyed (but not enough to complain harshly to the venue) by
the up-selling (and contemplates where the world has gone to when WiFi
isn't free), but is enjoying some of the walled garden resources offered by
the WISP for free.
User: Wow, that portal was super easy to use because I was already logged
into my social network (or maybe IETF website :) anyway

What actually happens today (made extra dramatic for effect :)
User: Wanting Wi-Fi, and already knows about years of reports about how
un-safe public WiFi is.
UE: Hey, btw, there is public access WiFi available
User: Click, yay! (Just like the IETF network!, oh, wait, there is a portal)
WISP: Dang, we aren't getting the data (or analytics on traffic) we once
got (or still get with no portal / garden)
WISP: Dang, the user isn't able to access our free walled garden resources
because the UE thinks they can't
WISP: Knows their portal is broken in some UEs (the marketing firm web
developers don't really understand limitations of walled gardens), gives
instructions on best way to invoke portal "reliably"
User: This portal is completely un-usable with UE, laptop is ok. I get they
are being cute with a social login, but it isn't working that well. I don't
remember any of my passwords.
User: They told me I could access information and certain Apps for free,
but I don't see how. This is pointless.
User: Complains to venue
Venue: Complains to WISP who adds capport detection URLs to the walled
garden

The arms race is a WISP trying to fix this user / UE / venue "public
access" expectation gap, by tweaking things to get the desired result (for
good intentions, or perhaps questionable).

This can be viewed as the UE as having different 'policies' for captive
portal public access networks vs. public access networks without portals.
One policy includes assuming all network connections will work (because the
UE did a DNS check plus some additional, rather statistically insignificant
URL tests), and puts the default route on the network without further ado.
The other, captive portal, policy (assigned even though the network
demonstrates general Internet connectivity via DNS tests, and maybe some of
the test URLs, the UE still wasn't convinced), disallows any network use
until the user performs actions in a broken browser of the UEs choosing
(and doing).

I think there are some user options to be had in there somewhere...

On Fri, Apr 7, 2017 at 12:01 PM, David Bird <[email-masked]> wrote:

>> I fundamentally do not understand what it is you're trying to say here.
>> I apologize for being thick.
>>
>>> A root cause of the so-called 'arms race' around captive portal
>>> detection that I'm trying to highlight is that it will always continue for
>>> as long as UEs treat captive portal networks specifically different than
>>> they do public access networks generally, you will have incentive to
>>> exploit that difference in behavior in the public access industry.
>>>
>>>> But, it DOES happen when you connect to Open SSID without captive
>>>> portal (or when the venue evaded your detection). Maybe the captive portal
>>>> If you had ICMP giving you real-time feedback, you could more
>>>> accurately (and quickly) detect what connections will work and which will
>>>> not on the network. QUIC will help in maintaining session continuity as
>>>> connections are pinned to different interfaces.
>>>>
>>>>
>>>>

---

From: Erik Kline <[email-masked]>
Date: Mon, 10 Apr 2017 11:53:06 +0900

> The ICMP reply could very well be used to trigger the teacher override.

This is an interesting point.  We should consider what types of access
restriction are in scope.

Consider zero-rating, for example.  Should the aim be to provide a general
hint of network restriction, or on a per-destination basis?

One difference in consideration is whether interaction with a captive
portal could theoretically provide remediation.  If so, perhaps a new code
under Destination Unreachable is best, and for those things that are
effectively "permanently unreachable" Administratively Prohibited might be
the best code.

---

From: Mark Nottingham <[email-masked]>
Date: Mon, 10 Apr 2017 13:07:42 +1000

> On 10 Apr 2017, at 12:53 pm, Erik Kline <[email-masked]> wrote:
> 
> 
> 
> This is an interesting point.  We should consider what types of access restriction are in scope.
> 
> Consider zero-rating, for example.  Should the aim be to provide a general hint of network restriction, or on a per-destination basis?

Our charter is expressed in terms of authorization for network access. I could see providing context about the quality of the Internet connection (a la BCP104), but allowing destination-by-destination granularity has some pretty significant potential impact; it will basically be giving the IETF's blessing to zero-rating, and in some markets that's a very contentious topic.

So, we need to proceed carefully. IMO, we don't need to provide a per-destination capability to meet the charter, and doing so could add significant risk to an already risky endeavour.

Cheers,

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

---

From: Erik Kline <[email-masked]>
Date: Mon, 10 Apr 2017 12:28:32 +0900

On 10 April 2017 at 12:07, Mark Nottingham <[email-masked]> wrote:

> > Consider zero-rating, for example.  Should the aim be to provide a
> general hint of network restriction, or on a per-destination basis?
>
> Our charter is expressed in terms of authorization for network access. I
> could see providing context about the quality of the Internet connection (a
> la BCP104), but allowing destination-by-destination granularity has some
> pretty significant potential impact; it will basically be giving the IETF's
> blessing to zero-rating, and in some markets that's a very contentious
> topic.
>
> So, we need to proceed carefully. IMO, we don't need to provide a
> per-destination capability to meet the charter, and doing so could add
> significant risk to an already risky endeavour.
>

As someone who has pushed back on zero-rating, I certainly feel the same.

While the charter does mention capital-"I" Internet, other parts are
expressed in terms of "limited environments", "parameters of confinement",
and other phrases.  I'm perfectly fine with zero-rating being a
non-objective.  =)

---

From: David Bird <[email-masked]>
Date: Sun, 9 Apr 2017 21:30:10 -0700

> effectively "permanently unreachable" Administratively Prohibited might be

Doesn't ICMP Dest Unreachable generally "aim to provide a general hint of
network restrictions", routing, firewall, or otherwise ? (Should we revisit
ICMP in general in light of zero-rating?)

I'm not taking a position on zero-rating, but that is essentially what a
walled garden is: content allowed before authorization. One use-case might
be designed for zero-rating, others might be to prevent kids from going to
unknown resources from the school network.

I don't know how you can mandate that 'authorization' is always free and
the walled garden isn't used for zero-rating...

---

From: Michael Richardson <[email-masked]>
Date: Mon, 10 Apr 2017 09:19:43 -0400

David Bird <[email-masked]> wrote:
    > Should the aim be to provide a

Consider access to higher bandwidth content (video).
A number of places might want to restrict access to such content during
certain periods, or from certain places.  A school might restrict it
during school hours (simply for fairness: people got other things to do),
yet a teacher ought to be able to stream an instructional video.
Colleges might restrict its use when in a lecture hall.

Airlines might want to restrict streaming video to those who paid more.
(So there might even be multiple levels of walled garden!)

My mobile ISP does not charge me "overages" but, rather limits my bit-rate
after I hit my datacap.  I can buy more; and they SMS me about it, but a
data-only plan wouldn't have an SMS attached to it.

All of these things would seem to be doable with the ICMP plus RESTful
API.    It seems that the session-ID can deal with these changes, and
the validity could indicate things like valid until the end-of-school day.

ICMP says:
   Any change in this value between ICMP messages
   from the same source IP address MUST be considered by the client to
   mean a change in access policy has occurred and previous
   notifications are no longer valid.

I don't know what it means if an ICMP comes from a different source IP.

---

From: David Bird <[email-masked]>
Date: Mon, 10 Apr 2017 06:40:51 -0700

Agreed. Except, I'd argue that the "API" could be seen as the browser
itself - the "universal" API that everyone is familiar with and that offers
endless possibilities. Today, browsers offer largely the same user
experience irrespective of OS or browser (of course, this isn't true if the
browser is a sandboxed/broken browser that forces web developers back into
the dark ages of huge differences between user experiences depending on
browser selection).

The API could add another 'layer' for announcing limitations, walled garden
resources, and other information, but my opinion is that if the information
didn't come from the *network*, why would you want to believe it? In public
access, there WILL be incentives to give misleading information from an
API. If you trust, you must still verify.

As for as API for login, as I previously mentioned, that already exists and
widely deployed and used. Replacing WISPr is a GOOD idea, but I question
whether there will be motivation to actually deploy it (unless we make a
mistake and it is useful for additional commercial trickery in public
access).

Thanks for reading my ICMP I-D ... comments are welcome! Yes, it could use
more attention and improvements... I encourage others to (re-)read it.

---

From: Mikael Abrahamsson <[email-masked]>
Date: Mon, 10 Apr 2017 15:52:25 +0200 (CEST)

On Mon, 10 Apr 2017, Michael Richardson wrote:

> API.  It seems that the session-ID can deal with these changes, and the 
> validity could indicate things like valid until the end-of-school day.

This is an interesting idea. MIF WG had the idea of PVDs. ALTO WG has the 
idea about "application-layer traffic optimization", and a server to tell 
you information. ALTO also has its own discovery mechanism for how to find 
the ALTO server. CAPPORT has its own proposal to do that. MIF also had 
PVD-prooposal, now being done in INT-AREA.

To me all these solutions seem to be very closely related in 
solution-space, and I wish we could all agree on one mechanism that could 
work for all use-cases.

It seems to me that you're now suggesting yet another one?

---

From: David Bird <[email-masked]>
Date: Mon, 10 Apr 2017 07:13:39 -0700

I think one difference in public access vs. other access is that in public
access (for right or wrong) there are commercial incentives to give you
misleading information in order to trick your device into behaving a
desired way.

I agree that (yet another) API might not be making anything easier. Which
is why I view RFC7710 + ICMP as a very simple solution, that builds on top
of basic, existing, 'building blocks'. DHCP/RA giving a bit of network
configuration (which it does today), and ICMP giving you feedback about the
fate of your packets (something it does today). The NAS isn't doing
anything different -- it is still deciding what gets through and what
doesn't. The NAS is probably already sending ICMP for blocked traffic (or
it isn't, leading to connection timeouts). Implementing the NAS portion is
super simple (and can be implemented in may places in your network -
iptables, separate rate limiter, etc).

I view this relatively SIMPLE protocol, which at its core is just telling
you the 'truth' (or at least as close as you can get to it, subject to the
same risks as ICMP in general) about what happened to your packets and why.

---

From: David Bird <[email-masked]>
Date: Mon, 10 Apr 2017 07:47:31 -0700

> effectively "permanently unreachable" Administratively Prohibited might be

Yes, remediation is a use-case unlocked by the Capport icmp I-D. It can
also be used to give you advanced notice of a pending change in your access
policy. It can also prompt 'remediation' without throwing you off the
network or blocking your traffic (something not even possible in Hotspot
2.0).

So, yes, new ICMP codes (as described in the I-D, both for 'terminal' and
'warning' ICMP messages) makes many use-cases possible, not just in public
access over Wi-Fi or wired, but also LTE and Hotspot 2.0 networks.

---

From: Michael Richardson <[email-masked]>
Date: Mon, 10 Apr 2017 10:57:49 -0400

David Bird <[email-masked]> wrote:
    > itself - the "universal" API that everyone is familiar with and that
    > offers endless possibilities. Today, browsers offer largely the same

I don't mind if there is a JS client available for download, but I feel that
the API needs to be real.   On my phone, many of the "core" interactions that
occur over HTTP do not use the stock browser:  Facebook (lite), G+, Hangout,
Strava,  Tripit, etc.

Secondly, in a classroom situation, it might be worth having the ICMP
receiver on the child's system do something different.  In particular
it can not open up the child's browser for the override code.
(Because the teacher will be subject to keystroke capture attacks by
the student)

    > As for as API for login, as I previously mentioned, that already
    > exists and widely deployed and used. Replacing WISPr is a GOOD idea,
    > but I question whether there will be motivation to actually deploy it
    > (unless we make a mistake and it is useful for additional commercial
    > trickery in public access).

okay, I don't know WISPr's capabilities.

---

From: David Bird <[email-masked]>
Date: Mon, 10 Apr 2017 08:08:43 -0700

Absolutely, within a 'closed' environment (e.g. where you have control over
your walled garden, what Apps are installed or offered to users, etc), you
can do all sorts of cool and clever things with custom interfaces, APIs,
and auto- or assisted- logins. This is true today for Hotspot operators
(within their own garden and App, they can do anything they want, more or
less). This is also true for roaming aggregators (they use their own APIs
accessed through the walled garden of Hotspots in their network). None of
these solutions require IETF or any standards... I think it is a mistake to
try and figure out a common API for everyone to use, as it will never fit
all use-cases. In my opinion, we can only create sort of 'core' protocols
to convey configuration and network feedback and let the industry decide
how it applies to their use-cases.

---

From: Mikael Abrahamsson <[email-masked]>
Date: Mon, 10 Apr 2017 17:09:58 +0200 (CEST)

On Mon, 10 Apr 2017, David Bird wrote:

> I view this relatively SIMPLE protocol, which at its core is just 
> telling you the 'truth' (or at least as close as you can get to it, 
> subject to the same risks as ICMP in general) about what happened to 
> your packets and why.

So while I don't have any objections to the ICMP method (but I would like 
to know what operating system implementors have to say about it), my point 
is more about what can be communicated using this option.

Would it for instance make sense for ALTO to also use this option? Do we 
have enough stuff in the ICMP type to say "please carry on what you're 
doing, but btw, here is an interesting URI to go to if you support X" 
where X, could be for instance ALTO protocol. It could be something else.

I don't really want to invent things only for the capport use-case, 
because it's not too distant from other use-cases. I really want to make 
sure that whatever we come up with here is generic enough so that it can 
be use for similar use-cases, for instance the PVD/network properties 
use-case.

So should the ICMP not be an "unreach" type, but something else? Should we 
include more codespace to have future codes that could signal something 
else? Perhaps there should be some TLV text field to signal future 
extensions? Should there be a version field so we don't have to use more 
ICMP code space in case we want to change the structure? The C-type does 
give extensibility, but perhaps there should be some kind of 
"informational" type as well? The icmp-unreach draft seems to be very much 
use-case focused, it's not really generic. Is this a good thing?

---

From: Lorenzo Colitti <[email-masked]>
Date: Tue, 11 Apr 2017 00:14:53 +0900

> when interacting with a captive portal.

In the case of Chrome, it's a technical limitation. The browser just
doesn't support using a network that is not the system default network, and
that is required to log into a captive portal without disrupting all other
Internet access on the device (e.g., email sync, incoming chat messages,
etc.).

The necessary work is both infrastructure (per-network socket pools,
per-network DNS requests, per-network change events, etc.) and UI - e.g.,
how to denote in the UI that a particular tab is tied to a particular
network.

Android provides an API that a multinetwork-aware app can use to offer to
log in to captive portals instead of the system default app. In order for
that to work the app must have the ability to display web pages on a
network that is not the system default network. IIRC there was some
interest from Firefox to implement this API, but I'm not sure whether they
ever did.

> get the “real” browser: cookies, video player, etc.

As regards the captive portal login app on Android: other than cookies,
which are technically impossible except by lifting the technical limitation
above, since they are in the Chrome app which has its own cookie store in
its own directory, what issues do you see?

---

From: David Bird <[email-masked]>
Date: Mon, 10 Apr 2017 08:21:04 -0700

On Mon, Apr 10, 2017 at 8:09 AM, Mikael Abrahamsson <[email-masked]>
wrote:

> doing, but btw, here is an interesting URI to go to if you support X" where
> X, could be for instance ALTO protocol. It could be something else.
>
>
Good point.. there are certainly other reasons to send someone to a
'portal' other than 'captivity' reasons.

> sure that whatever we come up with here is generic enough so that it can be
> use for similar use-cases, for instance the PVD/network properties use-case.
>
Yes, the I-D defines an Unreach+Capport-Extension and a top level Capport
type (the latter is designed NOT to be interpreted by Legacy devices).

Absolutely, we can improve the icmp I-D -- first step is to get a high
level acceptance of the ICMP approach.

As far as being use-case specific, you mean the captive portal use-case? (I
like to think that within captive portal use-cases, the ICMP concept is
actually very use-case agnostic). If so, I see you point... but, this is
the Capport WG. Perhaps we are now talking more generally about any
'network prompted portal interaction' ?

---

From: Mikael Abrahamsson <[email-masked]>
Date: Mon, 10 Apr 2017 17:57:38 +0200 (CEST)

On Mon, 10 Apr 2017, David Bird wrote:

> As far as being use-case specific, you mean the captive portal use-case? 
> (I like to think that within captive portal use-cases, the ICMP concept 
> is actually very use-case agnostic). If so, I see you point... but, this 
> is the Capport WG. Perhaps we are now talking more generally about any 

I'm talking about "general network information". For me CAPPORT use-case 
is one use-case for this kind of information. There are others.

CAPPORT doesn't have to just solve its own problems, perhaps it'd be good 
to try to come up with a slightly more generic solution and send it for 
review in INT-AREA for instance? I keep mentioning ALTO because I see 
their use-case as similar as well, but they invented their own discovery 
mechanism.

Also, the ICMP error we're talking about, is that feature parity with 
RFC7710? Because I would like to see DHCP options, RA options and ICMP 
messages all being able to do the same thing. I could even imagine the 
ICMP unreach message (perhaps very similar in content) be sent to a 
multicast group on the LAN, completely replacing the RA/DHCP option? Or we 
could do it using mDNS instead of in RA? Is there even work on feature 
parity using mDNS instead?

---

From: David Bird <[email-masked]>
Date: Mon, 10 Apr 2017 16:28:01 -0700

On Mon, Apr 10, 2017 at 8:57 AM, Mikael Abrahamsson <[email-masked]>
wrote:

>> (I like to think that within captive portal use-cases, the ICMP concept is
> review in INT-AREA for instance? I keep mentioning ALTO because I see their
> use-case as similar as well, but they invented their own discovery
> mechanism.
>
>
I took a quick look at ALTO. I'd have some concerns about the complexity
and the high incentive for "attacker" or hostile behavior. The 5 Security
subsections all seemed a bit scary, with the protection strategy for a
server wanting to provide misleading information:

   To protect applications from undesirable ALTO information resources,
   it is important to note that there is no protocol mechanism to
   require conforming behaviors on how applications use ALTO information
   resources.  An application using ALTO may consider including a
   mechanism to detect misleading or undesirable results from using ALTO
   information resources.  For example, if throughput measurements do
   not show "better-than-random" results when using an ALTO cost map to
   select resource providers, the application may want to disable ALTO
   usage or switch to an external ALTO server provided by an
   "independent organization" (see AR-20 and AR-21 in [RFC6708
<https://tools.ietf.org/html/rfc6708>]).

In public access networks, I think it is more appropriate to take the
information you get and: trust, but verify. DHCP/RA gives you the portal
URL, it might as well since it is also giving you your default route and
IP. The network is providing notification, because it might as well, it is
doing that anyway and the in-line components enforcing any limitation (NAS,
rate-limiting, etc) have the information they need.

> messages all being able to do the same thing. I could even imagine the ICMP
> unreach message (perhaps very similar in content) be sent to a multicast
> group on the LAN, completely replacing the RA/DHCP option? Or we could do
> it using mDNS instead of in RA? Is there even work on feature parity using
> mDNS instead?
>
>
>
No, the Capport ICMP protocol doesn't provide parity with rfc7710, rather
works in combination. My first draft allowed for the portal URL in the ICMP
message, but even with other precautions, the group quickly determined that
was too risky for threat of an ICMP message sending you to an arbitrary
site. It seems reasonable to separate 'notification' from 'configuration'
in this way...

---

From: Mark Nottingham <[email-masked]>
Date: Tue, 11 Apr 2017 09:46:17 +1000

> On 11 Apr 2017, at 1:57 am, Mikael Abrahamsson <[email-masked]> wrote:
> 
> CAPPORT doesn't have to just solve its own problems, perhaps it'd be good to try to come up with a slightly more generic solution and send it for review in INT-AREA for instance?

If I follow the discussion here and on the issues list correctly, I'm concerned.

My understanding when this WG was chartered was that we didn't really *like* captive portals, but people thought there was some benefit to at least making their operation smoother; we had lots of examples of interop problems and bad user outcomes in the discussion leading up to it. In that manner, the goal here AIUI is to codify current practice and incrementally improve it.

As I said in the BoF, even mitigating those problems might not lead to a great outcome, as it will encourage the deployment of more captive portals (as many networks are rolling them back, at least in my experience).

There is one use case defined in our charter:

"""
Some networks require interaction from users prior to authorizing
network access. Before that authorization is granted, network access
might be limited in some fashion. Frequently, this authorization process
requires human interaction to arrange for payment or to accept some
legal terms.
"""

Expanding the scope of this work to allow networks to further control their users' experience after authorisation to use the network (even if that is just giving a better user experience of that control) is not a small change. Allowing networks to interpose themselves in communication after authorisation is not a small change. 

AFAICT addressing these use cases would require re-chartering, and that's something I would argue vigorously against. I'd like to hear a clear statement from the Chairs about what they think the scope of work is here.

Regards,

---

From: David Bird <[email-masked]>
Date: Mon, 10 Apr 2017 17:15:03 -0700

On Mon, Apr 10, 2017 at 4:46 PM, Mark Nottingham <[email-masked]> wrote:

> > CAPPORT doesn't have to just solve its own problems, perhaps it'd be
> good to try to come up with a slightly more generic solution and send it
> for review in INT-AREA for instance?
>
> My understanding when this WG was chartered was that we didn't really
> *like* captive portals, but people thought there was some benefit to at
> least making their operation smoother; we had lots of examples of interop
> problems and bad user outcomes in the discussion leading up to it. In that
> manner, the goal here AIUI is to codify current practice and incrementally
> improve it.
>
>
Indeed, there is a distinct bias against captive portals, of all forms. We
all hate them, but we all still use them. (don't you?)  I also hate paying
taxes.

Often, venues don't want to use them either, but they need to for a variety
of reasons, some legal (as in they are legally required to display
something), but who are we to judge? Ideally, we get rid of http hijacking.
But, there will always be legacy devices - for the foreseeable future, and
you just can't say they aren't supported in public access (or not subject
to restrictions), nor can a network trust a device to always do what it is
told.

> As I said in the BoF, even mitigating those problems might not lead to a
> great outcome, as it will encourage the deployment of more captive portals
> (as many networks are rolling them back, at least in my experience).
>
> Expanding the scope of this work to allow networks to further control
> their users' experience after authorisation to use the network (even if
> that is just giving a better user experience of that control) is not a
> small change. Allowing networks to interpose themselves in communication
> after authorisation is not a small change.
>
>
But, alas, networks are already doing this and people are using these
networks (willfully, they can always pick another network). They just can't
do it in very elegant ways and still implement their business model. Who is
IETF to define what is an appropriate business model for public access, or
any access? Yes, I think the UE can do more to protect users and take the
front-seat in the user / provider expectation gap in public access -- which
is, users want it, providers have it, and UEs are increasingly making it
harder for both (for a couple of unrelated reasons).

I think we need to play both sides of the fence here, a little bit...
captive portals are not ALL bad! Not all use-cases are evil. Yes, in public
access you have evil twins and rogue APs, but I'd say, focus on making
objective and secure end-to-end protocols... nobody said the Internet was a
safe place.

(and we wonder why there isn't more industry activity in this WG?)

> AFAICT addressing these use cases would require re-chartering, and that's
> something I would argue vigorously against. I'd like to hear a clear
> statement from the Chairs about what they think the scope of work is here.
>
> Regards,
>
> --

---

From: Mark Nottingham <[email-masked]>
Date: Tue, 11 Apr 2017 10:28:09 +1000

Hi David,

I'm not arguing against helping improve the user experience of captive portals as they're commonly understood and currently deployed; I'm against expanding the definition of "captive portal" to give the network more control over communication *after the captive portal phase is done.*

Of course, networks already have significant power over what a user can and cannot do over them. Codifying this by standardising a way for networks to interpose themselves in subsequent communication, or pop up "helpful" information on the fly, or selectively refuse communication and offer replacement content -- all of which seem to be under discussion here -- is a pretty substantial expansion of that power, in practical terms. 

It may be that that's the right thing to do, but it'd need to be informed by a wider discussion. This was *not* the scope of work that I understood when this WG was chartered.

WRT your question about "who is the IETF to define what is an appropriate business model access" -- this is a question that is being taken seriously in the IETF, as evidenced by tech plenary session in Chicago. It's clear that we don't solely determine the balance of these things on the Internet, but it's just as clear that we do have some role to play; I think it'd be pretty poor if we just abdicated any responsibility to end users and said "let the market sort it out, we just write specs." At the very least, I'd expect a discussion of the effect these changes might have upon the Internet and people's access to it.

Regards,

> On 11 Apr 2017, at 10:15 am, David Bird <[email-masked]> wrote:
> 
> Indeed, there is a distinct bias against captive portals, of all forms. We all hate them, but we all still use them. (don't you?)  I also hate paying taxes.
> 
> Often, venues don't want to use them either, but they need to for a variety of reasons, some legal (as in they are legally required to display something), but who are we to judge? Ideally, we get rid of http hijacking. But, there will always be legacy devices - for the foreseeable future, and you just can't say they aren't supported in public access (or not subject to restrictions), nor can a network trust a device to always do what it is told.
> 
>  
> But, alas, networks are already doing this and people are using these networks (willfully, they can always pick another network). They just can't do it in very elegant ways and still implement their business model. Who is IETF to define what is an appropriate business model for public access, or any access? Yes, I think the UE can do more to protect users and take the front-seat in the user / provider expectation gap in public access -- which is, users want it, providers have it, and UEs are increasingly making it harder for both (for a couple of unrelated reasons). 
> 
> I think we need to play both sides of the fence here, a little bit... captive portals are not ALL bad! Not all use-cases are evil. Yes, in public access you have evil twins and rogue APs, but I'd say, focus on making objective and secure end-to-end protocols... nobody said the Internet was a safe place.
>

---

From: David Bird <[email-masked]>
Date: Mon, 10 Apr 2017 20:08:28 -0700

I don't think we disagree on much, at the end of the day. We agree we
should NOT be giving and additional abilities to anyone. There probably
shouldn't be any Capport "API".

DHCP/RA + ICMP is just annotating things that ALREADY happen. And, the
capport device doesn't need to do http URL 'discovery', it only needs to
listen for ICMP errors/warnings, the errors already exists, but 'warnings'
are new. However, that is just a non-connection-terminating error (in of
itself, no more harmful than errors themselves).

In terms of terminating a session and returning to portal, again, already
being done, ICMP just made it protocol agnostic and clients still don't
have to do http 'discovery' for being in captive state. In terms of not
*supporting* that ability, again, already being done... and a pretty well
established session parameter going back to RFC2865 and Session-Timeout.

Really, I think I'm proposing exactly what you stated: "improve the user
experience of captive portals as they're commonly understood and currently
deployed".

The "suggested portal feature", in my opinion, adds little harm (the
network *could* disconnect you entirely to get your attention that way),
adds value to user - mostly, sure it can be used to annoy, but the UE can
keep that from happening too much - and gives a good reason/motivation for
this standard to be deployed, adding value to (probably) the entire
ecosystem - user/venue/wisp/aggregator/vendors.

On Apr 10, 2017 5:28 PM, "Mark Nottingham" <[email-masked]> wrote:

> Hi David,
>
> I'm not arguing against helping improve the user experience of captive
> portals as they're commonly understood and currently deployed; I'm against
> expanding the definition of "captive portal" to give the network more
> control over communication *after the captive portal phase is done.*
>
> Of course, networks already have significant power over what a user can
> and cannot do over them. Codifying this by standardising a way for networks
> to interpose themselves in subsequent communication, or pop up "helpful"
> information on the fly, or selectively refuse communication and offer
> replacement content -- all of which seem to be under discussion here -- is
> a pretty substantial expansion of that power, in practical terms.
>
> It may be that that's the right thing to do, but it'd need to be informed
> by a wider discussion. This was *not* the scope of work that I understood
> when this WG was chartered.
>
> WRT your question about "who is the IETF to define what is an appropriate
> business model access" -- this is a question that is being taken seriously
> in the IETF, as evidenced by tech plenary session in Chicago. It's clear
> that we don't solely determine the balance of these things on the Internet,
> but it's just as clear that we do have some role to play; I think it'd be
> pretty poor if we just abdicated any responsibility to end users and said
> "let the market sort it out, we just write specs." At the very least, I'd
> expect a discussion of the effect these changes might have upon the
> Internet and people's access to it.
>
> Regards,
>
>
> > Indeed, there is a distinct bias against captive portals, of all forms.
> We all hate them, but we all still use them. (don't you?)  I also hate
> paying taxes.
> >
> > Often, venues don't want to use them either, but they need to for a
> variety of reasons, some legal (as in they are legally required to display
> > AFAICT addressing these use cases would require re-chartering, and
> that's something I would argue vigorously against. I'd like to hear a clear

---

From: Erik Kline <[email-masked]>
Date: Tue, 11 Apr 2017 12:40:10 +0900

> statement from the Chairs about what they think the scope of work is here.

Doffing my co-chair hat and speaking as a general Internet citizen, I too
would oppose such a thing.  We could end up with some kind of IETF
Signalling System 7 where we ask the network if we're permitted to make a
connection for each and every new connection like some kind of circuit
setup.

As a working group member, I do wonder how we might prevent abuse of any
"solutions" we design.

As a co-chair, I'm wondering whether, in addition to
draft-nottingham-capport-problem, we need a document describing the
limitations of any potential solution space.  (How does a client OS prevent
malicious apps costing the user money by auto-extending a billed session?
et cetera)

---

From: Dave Dolson <[email-masked]>
Date: Tue, 11 Apr 2017 04:22:02 +0000

Thinking about the plenary session and discussion of tussle, I think we should consider how to improve standardization in such a way that is fair to both parties. Doing nothing leaves the portal doing all the bad behaviors you documented so concisely in the problem statement.

Any access point has full control of client access to the Internet. I think we can improve the means this is signaled and presented to the user, while also removing any need for application-layer modifications of http or DNS.

David Dolson
‎
  Original Message
From: Mark Nottingham
Sent: Monday, April 10, 2017 8:28 PM
To: David Bird
Cc: Erik Kline; [email-masked]; Martin Thomson; Mikael Abrahamsson
Subject: Re: [Captive-portals] time-based walled gardens

Hi David,

Regards,

---

From: David Bird <[email-masked]>
Date: Mon, 10 Apr 2017 21:53:50 -0700

>> connection for each and every new connection like some kind of circuit
I'd argue that no network can guarantee you a route to your destination. A
walled garden might be an extreme case, but it could be extreme either
direction; really small or large. ICMP Dest Unreach is already giving the
client feedback on drops and network restrictions; route and firewall. I
think the only limitations are in software :)

> As a working group member, I do wonder how we might prevent abuse of any
I think 'abuse' in this case is a relative term, and can apply to public
access networks and their users.

> malicious apps costing the user money by auto-extending a billed session?
If we don't have an API, how would an malicious app extend the session?

---

From: Mikael Abrahamsson <[email-masked]>
Date: Tue, 11 Apr 2017 09:03:20 +0200 (CEST)

On Tue, 11 Apr 2017, Mark Nottingham wrote:

> that's something I would argue vigorously against. I'd like to hear a 
> clear statement from the Chairs about what they think the scope of work 
> is here.

I am not talking about control, I am talking about information. PVD is 
about information, ALTO is also about information.

For instance, I don't see a reason for CAPPORT to have its own RA option 
when a more generic one could be used for both CAPPORT and MIF PVD 
information. Unofrtunately I was "asleep" when the RA option was sent to 
6man for review. Both (RA/DHCP) are about providing information to devices 
on the network. ALTO is also about providing information.

So I guess what I'm saying is that I think it's a mistake to just make the 
work here, looking only at the CAPPORT use-case, and looking nowhere else. 
A more generic option, if not allowed by the charter to be done here, can 
be done in INT-AREA or 6man or somewhere else.

I don't like captive portals, I want them to die. But there are other 
use-cases for providing information to devices and I'd hate to have siloed 
solutions for every problem-space. I'd love to hear from implementors what 
their view is, do they want more specialised ways of doing things, or 
fewer more generic ones.

---

From: David Bird <[email-masked]>
Date: Tue, 11 Apr 2017 05:32:28 -0700

> about information, ALTO is also about information.
Information can be used to control.

> on the network. ALTO is also about providing information.
I think you can view all DHCP options as providing information about the
network. Just because two options use a URL, doesn't mean the information
is the same or even relevant for the use-case. Overloading existing
mechanisms would make security considerations far more difficult.

We already have RFC7710. I wasn't involved in that, and I agree it could
have probably used more review. As it is now, it adds no value. However, it
provides a starting point, and combined with ICMP it starts completing the
picture.

> their view is, do they want more specialised ways of doing things, or fewer
> more generic ones.
>

Seriously? What implementor of captive portals would want to comment in
this (anti-)capport WG? Sure, you can probably find a couple venues that
were forced to use a captive portal, but didn't want to (I can't think of
an example, but maybe you can). We could design solutions for just them,
but is that a sizable market for vendors?

---

From: Mikael Abrahamsson <[email-masked]>
Date: Tue, 11 Apr 2017 14:56:43 +0200 (CEST)

> Seriously? What implementor of captive portals would want to comment in

Implementor of operating systems, not implementors of captive portals.

---

From: Niall Hogg <[email-masked]>
Date: Tue, 11 Apr 2017 21:06:38 +0800

Either way, opinions about the morality of captive portals are entirely irrelevant regardless of intended audience. The fact is that captive portals exist for a wide variety of reasons, technical and legal. It is beyond the remit of this committee to make any comment one way or another.

> On 11 Apr 2017, at 20:56, Mikael Abrahamsson <[email-masked]> wrote:
>

---

From: Mikael Abrahamsson <[email-masked]>
Date: Tue, 11 Apr 2017 16:05:13 +0200 (CEST)

On Tue, 11 Apr 2017, Niall Hogg wrote:

> Either way, opinions about the morality of captive portals are entirely

Morality? I was asking for technical input, if (for instance) Android/iOS 
implementors would like to have network information sent to them in 
multiple protocols depending on where in the IETF it's done, or if they'd 
prefer a fewer protocols/methods that are more generic.

---

From: David Bird <[email-masked]>
Date: Tue, 11 Apr 2017 07:16:29 -0700

I believe we both were referring more to the comment: "I don't like captive
portals, I want them to die. "

I know that wasn't your main point, but it is seems to be a feeling shared
among some in this WG.

---

From: Christian Saunders <[email-masked]>
Date: Tue, 11 Apr 2017 16:05:23 +0000

As a Captive Portal infrastructure architect for a Wi-Fi operator my bias should be clear.

We use the Captive Portal to assist in customer on-boarding and to provide an improved user experience to users who are not entitled to access.

That being said, it is possible that a captive portal could be used for abuse.

Similarly, there is abhorrent traffic transmitted via HTTP but I certainly don't want this protocol to die.

My hope would be for the group to move on to more relevant topics.

Cheers!

Christian

Christian Saunders
Shaw Communications Inc.

On 17-04-11 08:16 AM, David Bird wrote:
I believe we both were referring more to the comment: "I don't like captive portals, I want them to die. "

I know that wasn't your main point, but it is seems to be a feeling shared among some in this WG.

On Tue, Apr 11, 2017 at 7:05 AM, Mikael Abrahamsson <[email-masked]<mailto:[email-masked]>> wrote:
On Tue, 11 Apr 2017, Niall Hogg wrote:

Morality? I was asking for technical input, if (for instance) Android/iOS implementors would like to have network information sent to them in multiple protocols depending on where in the IETF it's done, or if they'd prefer a fewer protocols/methods that are more generic.

---

From: Martin Thomson <[email-masked]>
Date: Tue, 18 Apr 2017 10:50:44 +1000

> status) of the FQDN. It is not some URL with questionable formatting...

I think that you missed my point.

The foundation for HTTPS is that there is an expectation of server
identity when navigation is initiated.  The same cannot be said in
this context.

---

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

In this context, one advantage is that the user device knows this is a special URL. It knows exactly why it is being presented. We may recommend the user be made clearly aware.

I think it is clearer than some random http or DNS that might be redirected (methods currently available)

David Dolson
‎
  Original Message
From: Martin Thomson
Sent: Monday, April 17, 2017 8:50 PM
To: David Bird
Cc: Michael Richardson; Martin J. Dürst; [email-masked]
Subject: Re: [Captive-portals] Arguments against (any) Capport "API"

---

From: Erik Kline <[email-masked]>
Date: Sun, 23 Apr 2017 21:20:01 +0900

On 12 April 2017 at 01:05, Christian Saunders <[email-masked]>
wrote:

> We use the Captive Portal to assist in customer on-boarding and to provide
> an improved user experience to users who are not entitled to access.
>

Indeed.  And it seems like we have.

Just to be clear, I think it only makes sense for us to speak and work in
terms of network access as a whole, per our charter.

I originally brought up zero rating because I saw some potential for
abuse.  But there are many such pitfalls, and we'll just have to be
cautious and address the ones we can in our documents.

I think we have some promising avenues for forward motion, in the ICMP and
architecture documents, but more on that in a separate thread.