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

[David Bird <[e-mail]>]

+captive-portals

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

> On Mon, Feb 5, 2018 at 12:03 PM, Martin Thomson <[e-mail]>
> wrote:
>
>> On Tue, Feb 6, 2018 at 5:03 AM, David Bird <[e-mail]> wrote:
>> [snip]
>
> 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
>> stapling.
>>
>>
> 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).
>
>