On Tue, Feb 6, 2018 at 5:03 AM, David Bird <[email protected]> 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? _______________________________________________ Captive-portals mailing list [email protected] https://www.ietf.org/mailman/listinfo/captive-portals
