Re: [Captive-portals] I-D Action: draft-ietf-capport-architecture-00.txt
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: tpa...@apple.com [mailto:tpa...@apple.com] Sent: Thursday, November 2, 2017 7:59 PM To: captive-portals@ietf.org; draft-ietf-capport-architect...@ietf.org 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 sur
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. Section 1: I would remove the parentheses around the statement “(However, this document does not yet…” 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? 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. Section 2.2.2: The summary of the PvD approach is good. We should update the references to [draft-ietf-intarea-provisioning-domains]. 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. 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. • 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. • 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. • 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. • 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”. 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. 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? > On Sep 29, 2017, at 6:33 AM, internet-dra...@ietf.org wrote: > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a
