[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


On Mon, Feb 5, 2018 at 1:40 PM, David Bird <[email protected]> wrote:
On Mon, Feb 5, 2018 at 12:03 PM, Martin Thomson <mar[email protected]> wrote:
On Tue, Feb 6, 2018 at 5:03 AM, David Bird <[email protected]> wrote:
I have heard UE vendors express a strong desire to be able to know
about status before they attempt to use the network.

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. 

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

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

Locations will often whitelist the necessary resources for the browser's sake...

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

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

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

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

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