[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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!


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, [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