Tommy, Thanks for the careful review. Please see inline [DD] comments. Changes I've made can be seen on github. https://github.com/capport-wg/architecture/commit/7aadf5a140b4876b074e09b6387382d77430c301
As for the unresolved issues below, after some list discussion we should raise issues in github. See "*issue*" below. -Dave -----Original Message----- From: [email protected] [mailto:[email protected]] Sent: Thursday, November 2, 2017 7:59 PM To: [email protected]; [email protected] Subject: Re: [Captive-portals] I-D Action: draft-ietf-capport-architecture-00.txt Hi Kyle, Dave, Thanks for updating the architecture document! It's nicely written, and serves as a very good summary of the state of our collective thoughts in the WG. I've just done a pass of a review of the document, and wanted to share my notes/thoughts with you and the rest of the group for discussion. Details below! Best, Tommy Section 1: The principles in general are great! I’m not sure about this one: “Solutions SHOULD allow a device to be alerted that it is in a captive network when attempting to use any application on the network. (Versus requiring a user to visit a clear-text HTTP site in order to receive a notification.)” I would possible modify the requirement to be: “Solutions SHOULD allow a device to be alerted that it is in a captive network before and in response to any attempt by an application to use the network.” It’s very similar, but we’re likely fine if we know before the attempt (as part of attachment) or as a notification in response to a failed connection. [DD] I think we could do this as two principles: (a) notification when using any protocol and (b) querying before using data. So would it be acceptable to add a NEW bullet: [DD] "Solutions SHOULD allow a device to learn that it is in a captive network before any application attempts to use the network." [DD] I will make that change on github, presuming it is OK. Section 1: I would remove the parentheses around the statement “(However, this document does not yet…” [DD] OK, done. Section 1: I don’t see a large different between the mechanism “End-user devices are notified of captivity with ICMP/ICMP6” and “Receipt of the ICMP/ICMP6 messages informs an end-user device”. Is this just trying to split the network behavior from the device behavior? [DD] Yes, I think these 3 bullets identify the things that happen. In the 2nd bullet "devices are notified". In the 3rd bullet, "device SHOULD query the provisioned API". [DD] Personally, I think it is important that the 3rd bullet is independent. There might be reasons for not implementing that behavior. Section 2.1: I would upgrade distinguishing Captive Portal API per-interface to a SHOULD from a MAY. While mPvD is a way to view it, any UE that has multiple interfaces (PvDs) really should not be treating all as captive, if only one is captive. Captive servers are prime examples of resources that are likely local to your attachment. [DD] I agree that was our intent. I will update it. Section 2.2.2: The summary of the PvD approach is good. We should update the references to [draft-ietf-intarea-provisioning-domains]. [DD] Reference updated. Later on, in Section 6, you mention how PvDs are trying to tie the authenticity of the JSON API server to the RA/DHCP provisioning; that may be a useful point to bring up to the initial discussion in 2.2.2. [DD] Would it be appropriate to say, "The PvD security model provides secure binding between the information provided by the trusted Router Advertisement, and the HTTPS server." ? [DD] Tentatively added to the document. Areas I’d like to discuss with the group around PvDs, or the currently specified DHCP option: • Clearly, the DHCP option needs more specification to point to an API (protocol, etc) beyond the current RFC, as discussed in 2.2.1. I’d love to see this update as opportunity for 2.2.1 and 2.2.2 to converge, however that makes most sense. [DD] Yes, it seems we should update or deprecate RFC7710. [*issue*] • A difference of the PvD option is that it allows for finer granularity, i.e. that you can have multiple PvDs/access routes on a single layer 2 interface (two uplinks on one Wi-Fi). One may be captive, the other not. Of course, we can specify that the DHCP/RA option for CAPPORT API URL will be associated with the PvD that shares the RA packet, so that’s solvable. [DD] Why wouldn't RFC7710 apply per route as well? (If clarified.) • We need to have a story around authentication that the CAPPORT API is actually provisioned by the same entity that provides the DHCP/RA. That can either be an auth option separately, or by using authentication of the PvD if we tie the captive option to a PvD. [DD] I think everyone would agree it is the same business entity. Otherwise, I'm not sure I appreciate what you are saying. • One discussion that’s come up is that a PvD API set of options will likely be longer-lived and less user-specific than the results in a CAPPORT API. The solution currently outlined here says that the device would first fetch the PvD API blob, which would point to the CAPPORT API. That works, and we may not care, but I don’t love the indirection here. Of course, the two *could* be co-located, even if one points to the other. My other thought (which may be harebrained) is that the option we get in RA/DHCP could essentially be able to point you to two different kinds of URLs: one for long-lived network-wide state, and one for more dynamic per-device state. These would have different fetching schemes, and the option would communicate the presence or non-presence of each. [DD] As I am thinking of it, there is not indirection to a capport API, rather the PvD API indicates state of captivity, with a URI pointer to the user interface. *issue* [DD] In PvD architecture, is it a problem to repeatedly query it, vs. only when joining the network? • The current DHCP option doesn’t have a way to say “there’s no captive portal to talk to”, so whenever we don’t see it, we’ll need to send a probe. So every network would either be one with a probe (thus delaying our full attachment), or one that is explicitly captive. Whatever we end up with, I’d like to see that be able to be avoided. Making the option a bit more generic (like PvD) would allow having defined semantics around the option saying “I’m a network that knows what I’m doing, and I don’t have a captive portal for you to interact with”. [DD] I like this idea. Further update to RFC7710, and/or to PvD? *issue* Section 2.3: Any thoughts on upgrading the TLS (or some other authenticated channel) support for the CAPPORT API to a MUST? Section 6.2 assumes this. [DD] That seems reasonable. I will make that change in the hopes it won't be controversial. Section 3.2: Could there be a sub-workflow for the case in which the UE predicted an expiry based on the CAPPORT API, and re-checks in before user has to have anything blocked, get ICMP, etc? [DD] I hope so. It must not be an error for the user equipment to call the API at any time. (Abusive use aside.) [DD] Do you think a new workflow is required to explain this? > On Sep 29, 2017, at 6:33 AM, [email protected] wrote: > > > 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 : CAPPORT Architecture > Authors : Kyle Larose > David Dolson > Filename : draft-ietf-capport-architecture-00.txt > Pages : 14 > Date : 2017-09-28 > > Abstract: > This document aims to document consensus on the CAPPORT architecture. > DHCP or Router Advertisements, ICMP, and an HTTP API are used to > provide the solution. The role of Provisioning Domains (PvDs) is > described. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-capport-architecture/ > > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-capport-architecture-00 > https://datatracker.ietf.org/doc/html/draft-ietf-capport-architecture- > 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/ > > _______________________________________________ > Captive-portals mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/captive-portals _______________________________________________ Captive-portals mailing list [email protected] https://www.ietf.org/mailman/listinfo/captive-portals
