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

[Martin Thomson <[e-mail]>]

On Tue, Feb 6, 2018 at 5:03 AM, David Bird <[e-mail]> wrote:
> Thanks Darshak and Tommy, this is really helpful.

Yes, thank you both.

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

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

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

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.

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