Subject: [Captive-portals] I-D Action: draft-ietf-capport-api-00.txt

From: [email-masked]
Date: Sun, 04 Feb 2018 15:02:31 -0800

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Captive Portal Interaction WG of the IETF.

        Title           : Captive Portal API
        Authors         : Tommy Pauly
                          Darshak Thakore
	Filename        : draft-ietf-capport-api-00.txt
	Pages           : 6
	Date            : 2018-02-02

Abstract:
   This document describes an HTTP API that allows hosts to interact
   with a Captive Portal system.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-capport-api/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-capport-api-00
https://datatracker.ietf.org/doc/html/draft-ietf-capport-api-00

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: David Bird <[email-masked]>
Date: Mon, 5 Feb 2018 10:03:53 -0800

Thanks Darshak and Tommy, this is really helpful.

Some comments:

In 2. Workflow: Does it make sense to reorder 2) and 3)? It would seem
'Enforcement' should come before determining status (of said enforcement)
and how to proceed. I would argue that the UE might as well try to use the
network and wait for the network to respond (e.g. with Enforcement and/or
routing notifications/errors. Indeed, the UE sorta already *did* this if it
resolved DNS and checked certificate status of the API server hostname.

In 3.1 URI of Captive Portal endpoint, I think we must go beyond making TLS
a MUST --- we need to define how trust is handled. We must require the API
client to validate the hostname, present that hostname to the user for
acknowledgement. Or, are we explicitly saying that TLS is for privacy and
not security? (e.g. that we really don't care what the server cert is...
just that the cert is consistent for that location / domain?). Is the
client expected to check revocation lists?

In 3.2, ' "permitted" (required, boolean): indicates whether or not the
Captive Portal is open to the requesting host ' is confusing... does it
mean the UE is subject to a captive portal?  I dislike how boolean this is!
Why does it have to be all or nothing (especially if ICMP is providing
enforcement notification?)

Also in 3.2, I'm not sure about the time/data remaining info.. Is the
expectation that the client keeps polling? (never goes idle on any
network?) Is the expectation that the UE  will break connections after it
sees this API expire timer or counter, or shall the (smart) UE wait until
the network notification (ICMP) ?

I think it would be idea to keep ICMP focused on network notification and
we can use the API more for validation and improving the security (and user
interaction) of ICMP.

Cheers,
David

On Sun, Feb 4, 2018 at 3:02 PM, <[email-masked]> wrote:

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

---

From: Martin Thomson <[email-masked]>
Date: Tue, 6 Feb 2018 07:03:35 +1100

> Thanks Darshak and Tommy, this is really helpful.

Yes, thank you both.

> resolved DNS and checked certificate status of the API server hostname.

I have heard UE vendors express a strong desire to be able to know
about status before they attempt to use the network.

> just that the cert is consistent for that location / domain?). Is the client
> expected to check revocation lists?

Good point.  This is likely an architecture question in the sense that
we need to determine what the trust model is and where that is
anchored.  We have an established pattern already where we trust that
the initial bootstrapping protocols (DHCP, RAs) produce a URL that is
accurate.  Once you have a URL, the rest of the process needs to
follow the rules: clients are expected to follow the usual rules for
server authentication.

In this particular case, we should explore that last point further,
because CRLs or OCSP are likely to fail in this sort of environment.
That's relatively easy to address, but we would have to mandate OCSP
stapling.

I've opened an issue: https://github.com/capport-wg/api/issues/7

> Captive Portal is open to the requesting host ' is confusing... does it mean
> the UE is subject to a captive portal?  I dislike how boolean this is! Why
> does it have to be all or nothing (especially if ICMP is providing

Can you motivate something less boolean?  That's a question we've
struggled with.

> expectation that the client keeps polling? (never goes idle on any network?)
> Is the expectation that the UE  will break connections after it sees this
> API expire timer or counter, or shall the (smart) UE wait until the network
> notification (ICMP) ?

I think that the way this is intended to work is that the UE will
contact the actual portal some time in advance of this time.

Why do you ask about polling?  Are there networks that will extend
active time in the case that clients go idle?

---

From: David Bird <[email-masked]>
Date: Mon, 5 Feb 2018 13:41:33 -0800

+captive-portals

On Mon, Feb 5, 2018 at 1:40 PM, David Bird <[email-masked]> wrote:

> On Mon, Feb 5, 2018 at 12:03 PM, Martin Thomson <[email-masked]>
> wrote:
>
>> [snip]
> Hm, but (assuming you are using the provided network for DNS, CRL checks,
> and the API itself), the UE is *already* using the network.
>
> I believe this desire on the UE vendor part is a case of 'be careful what
> you wish for' ... Having an API telling you it is "all clear" vs "do
> internal (often sandboxed for various reasons browser) captive portal
> dialog" amounts to making this a configuration of the network administrator
> -- Remember the (current) arms race concerning captive  portal detection?
> Well, the network operator wins with this API (!).
>
> As I've said before, I predict said vendors will quickly be of a different
> mind when support calls come in concerning how their new product gets (and
> perhaps is stuck) thinking there is a captive  portal, when in fact, there
> isn't one implemented and other devices work just fine... This API will be
> obsoleted a few months later.
>
>
>
> Locations will often whitelist the necessary resources for the browser's
> sake...
>
>
>
>> mean
> Over the years on this list we have seen many use-cases come through, I
> recall:
>
> -  A school/library network that allows most of the Internet, but captures
> and redirects for certain networks / sites
> -  A network allows all sorts of protocols - IMAP, HTTPS, for example -
> but not others - like HTTP, SMTP - and want to redirect / signal portal
> -  A network that allows all Internet traffic, but just at a low QoS tier.
> No "captive" portal, but a portal is  yet available for upgrading tier
> -  Any network that allows a large walled garden, or even a *very large*
> garden, but otherwise has a captive portal
> -  A network that will 99.99% of the time allow all traffic, but will
> (perhaps because of virus detection) interrupts sessions  into captive
> state [technically, this is a "boolean" use-case, but one where polling
> would just be huge noise]
>
> I know where were more ... ;)
>
>
>> network?)
> Clients that go idle typically have their session terminated - so, yes, it
> does save the user time (depending on "time" is billed - real time vs
> metered, etc).
>
>

---

From: Martin Thomson <[email-masked]>
Date: Tue, 6 Feb 2018 11:54:37 +1100

> and the API itself), the UE is *already* using the network.

Not really.  The way I understand it, the UE alters routing tables so
that only applications that explicitly opt in to using the interface
to the network can do so.  That state exists until the network is
given an "all clear".

> Well, the network operator wins with this API (!).

Remember we already concluded that if the network wants to lie about
status, we aren't planning to stop them.  There are still some
discussions to be had about providing incentives to be truthful, but
it's possible that we could never really plumb the depths of that
issue productively, so we've been deferring it.

> (perhaps because of virus detection) interrupts sessions  into captive state
> [technically, this is a "boolean" use-case, but one where polling would just
> be huge noise]

I'd say that the amount of information provided here is rich enough
that you want to talk to a human.  Very few networks permit sending of
arbitrary packets to arbitrary hosts and the receipt of similar.  The
point is to ensure that you are managing expectations.  If I
understand the expression of requirements, the idea is that a UE can
use the boolean signal, but this other stuff is better presented on
the web page.  If the network starts off in a captive state, then that
page will be seen (if there is a human), and maybe not used (if there
isn't).

> does save the user time (depending on "time" is billed - real time vs

Right.  Though this is relatively rare in my experience.  In those
cases, I think that the idea is that the client can check with the API
before its time comes due and notice the resulting extension and so go
back to sleep.

---

From: Tommy Pauly <[email-masked]>
Date: Mon, 05 Feb 2018 17:04:33 -0800

> On Feb 5, 2018, at 4:54 PM, Martin Thomson <[email-masked]> wrote:
> 
> given an "all clear”.

That’s correct—the device chooses how to expose the available interfaces/PvDs to the applications. If we have a cellular connection, for example, we won’t let any application traffic use the Wi-Fi network until we’re sure that it’s not captive (as far as we can tell).

> issue productively, so we've been deferring it.

Right, we can’t know for sure that the network isn’t lying. We have to trust that in the same way we trust the provisioning of DHCP, etc. We don’t need to make it such that no captive network can pretend to be non-captive, but we do need to allow some captive networks let the devices known that they are captive.

> before its time comes due and notice the resulting extension and so go

An idle device will still time out if nothing checks in, but for a device that is actively using the network and will be timeout at some specific threshold, it is useful to allow the user to re-up the connection.

---

From: David Bird <[email-masked]>
Date: Mon, 5 Feb 2018 17:07:15 -0800

> to the network can do so.  That state exists until the network is

I understand that. But, *really*, the application(s) that opt-in, as it
were, are using the  network... DNS, HTTPS (to the API), etc.

I'm not overly comfortable designing network protocols around, basically,
UE limitations and easy of programming... The  UE *could* be more
flexible...

> issue productively, so we've been deferring it.
My point is... that the reason for the "arms race" is user expectations and
the UE trying to determine possible issues in the network... My prediction
remains that the UE vendors will *still* opt to test the network even with
the API -- because they still have users, with expectations...

> state
I'm not sure I follow that statement...

> before its time comes due and notice the resulting extension and so go

What's rare, metered time based access??

---

From: Lorenzo Colitti <[email-masked]>
Date: Tue, 6 Feb 2018 13:40:07 +0900

> UE limitations and easy of programming... The  UE *could* be more

You're splitting hairs here. The UE does not ban applications from using
the captive network in the sense that applications can choose to use it if
they wish to. One notable use case is applications whose goal is to log
into captive portals automatically by leveraging existing credentials. So
Martin's original statement could be worded as "UE vendors express a strong
desire to be able to know about status before they inflict the network on
apps that want Internet access".

---

From: Martin Thomson <[email-masked]>
Date: Tue, 6 Feb 2018 16:02:05 +1100

> I'm not sure I follow that statement...

I'll try again, because that was a little dense.

You asserted (or implied) that a Boolean value was insufficiently
expressive to convey the range of possible policies that a captive
network might impose.  I asserted that while that is true, whatever
you do will be turned into a go/no-go decision by the UE.  This value
is giving the network provider a direct input to that decision.

I acknowledge that you might conclude that we're back to gaming this
out, but I have heard UE vendors say that they really don't want to
probe.  So if the network says that it's good, I think that they will
save the probing for when the network breaks instead.  But we'll let
Tommy and Lorenzo respond.

---

From: Lorenzo Colitti <[email-masked]>
Date: Tue, 6 Feb 2018 14:12:10 +0900

On Tue, Feb 6, 2018 at 6:41 AM, David Bird <[email-masked]> wrote:

>> -  A school/library network that allows most of the Internet, but
>> captures and redirects for certain networks / sites
>> -  A network that allows all Internet traffic, but just at a low QoS
>> tier. No "captive" portal, but a portal is  yet available for upgrading tier
I don't see why you would want to signal any of these to the UE, because
they're not really actionable. Even if the UE distinguishes between these
categories, application developers are likely not going to want to do so
and in the main are going to do whatever the UE decides to do. As Martin
says, the human using the UE might be interested (e.g., in the upgrading
case), but that's not hard to do by simply declaring a captive portal that
goes away if said human decides to dismiss the upsell opportunity or read
whatever message it is is that the operator would like them to read.

---

From: David Bird <[email-masked]>
Date: Tue, 6 Feb 2018 05:37:51 -0800

I don't follow... Yes, the signaling *would* be actionable...

- In the case of the school / library -- certain networks and / or
hostnames get you a captive portal notification (even if not HTTP) tell you
about your limitations

- In the case of the network that doesn't allow HTTP and SMTP (or other
protocols) you get a captive portal notification (even if not using HTTP)

- In the case of the lowered tier network ... The point here is that
network doesn't NEED to have everyone go through the portal (or even both
everyone with the portal before using the network)... The notification can
come later, for instance, when the network starts dropping pkts because of
the user's usage. How does a user change their mind, move to a new location
and start over?

---

From: David Bird <[email-masked]>
Date: Tue, 6 Feb 2018 05:58:31 -0800

Thanks Martin,

> is giving the network provider a direct input to that decision.
That is exactly right. All it does is make this a network operator decision
(not just input). It doesn't mean the network will actually work as
expected, of course...

> Tommy and Lorenzo respond.

Indeed, we want probing to go away... I am 100% in favor of using the
network (without probing) until the "network breaks instead" -- indeed, why
not use the network resources until it "breaks" either abruptly (dropped
packets, etc) or nicely (with cappport ICMP).  I know... that isn't easy
:-)

---

From: David Bird <[email-masked]>
Date: Tue, 6 Feb 2018 06:37:42 -0800

> apps that want Internet access".

Just a quick reminder that not only multi-network mobile phones use WiFi
hotspots...

My question is... how does an App know if it wants to use the network or
not? Even if there is a captive portal, maybe the App in question will work
just fine within the walled garden. Indeed, maybe the system OS might use
the walled garden (*free!*) resources for an OS upgrade download. I don't
see how the UE or App can really know if any network is suitable for any
application, in the general sense, irrespective of captive portals. What we
(generally) need is some magic in multi-homed devices that helps Apps find
the best (cheapest/fasted) network for them to run in -- but that is for
another working group. I know this is rather idealistic :-)

What I am concerned about is forming the protocols for capport around the
current design / implementation limitations for multi-homed networked
devices..

[Hypothetical UE design: When the user opt into a network, the default
route is moved over. As apps use the network, they may generate ICMP
notifications which prompt API queries and the App(s) in question being
restarted pinned to the existing known good network (perhaps with a captive
portal dialog in there somewhere). The same could  be done for App(s)
otherwise not getting network responses (e.g. routing or capacity problems,
etc).]

---

From: Michael Richardson <[email-masked]>
Date: Wed, 07 Feb 2018 16:19:03 -0500

David Bird <[email-masked]> wrote:
    > My question is... how does an App know if it wants to use the network
    > or not? Even if there is a captive portal, maybe the App in question
    > will work just fine within the walled garden. Indeed, maybe the system

Requires MIF and provisioning domains and lots of other magic goo.
(I personally don't believe MIF's provisioning domains solved the problem,
except for providing job security to marketing people at Telcos)

    > OS might use the walled garden (free!) resources for an OS upgrade
    > download. I don't see how the UE or App can really know if any network

To make your point, many airport WIFIs will let you see gate info without
logging in.  If that ever became an portable API, it would be very useful to
have an APP that watched that info for you.  And any restaurant or coffee
shop that didn't let you see the menu/price list without friction is being dumb.

    > is suitable for any application, in the general sense, irrespective of
    > captive portals. What we (generally) need is some magic in multi-homed
    > devices that helps Apps find the best (cheapest/fasted) network for
    > them to run in -- but that is for another working group. I know this
    > is rather idealistic :-)

So, what we need to do is not get in the way of other solutions.
I believe that IPv6 provides a number of solutions which are impossible in
IPv4, but there are chicken and egg problems with getting them deployed.

    > notifications which prompt API queries and the App(s) in question
    > being restarted pinned to the existing known good network (perhaps
    > with a captive portal dialog in there somewhere). The same could be
    > done for App(s) otherwise not getting network responses (e.g. routing
    > or capacity problems, etc).]

Sounds reasonable.

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

---

From: Michael Richardson <[email-masked]>
Date: Wed, 07 Feb 2018 16:22:11 -0500

Lorenzo Colitti <[email-masked]> wrote:
    > Over the years on this list we have seen many use-cases come
    > through, I recall:

    > - A school/library network that allows most of the Internet,
    > but captures and redirects for certain networks / sites
    > - A network allows all sorts of protocols - IMAP, HTTPS, for
    > example - but not others - like HTTP, SMTP - and want to
    > redirect / signal portal

    > - A network that allows all Internet traffic, but just at a
    > low QoS tier. No "captive" portal, but a portal is yet
    > available for upgrading tier
    > - Any network that allows a large walled garden, or even a
    > *very large* garden, but otherwise has a captive portal

    > - A network that will 99.99% of the time allow all traffic,
    > but will (perhaps because of virus detection) interrupts
    > sessions into captive state [technically, this is a "boolean"
    > use-case, but one where polling would just be huge noise]

    lc> I don't see why you would want to signal any of these to the UE,
    lc> because they're not really actionable. Even if the UE distinguishes

Not actionable by an UE.
Might other things care?

Is it useful for diagnostics?
(Why doesn't webrtc work here?)

    lc> between these categories, application developers are likely not going
    lc> to want to do so and in the main are going to do whatever the UE
    lc> decides to do. As Martin says, the human using the UE might be
    lc> interested (e.g., in the upgrading case), but that's not hard to do by