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