> On Jul 13, 2018, at 7:58 AM, David Bird <[email protected]> > wrote: > > Hi Tommy, > > Thanks for the reply... See one follow-up inline. > > > On Mon, Jul 9, 2018 at 4:33 PM Tommy Pauly <[email protected] > <mailto:[email protected]>> wrote: > Hi David, > > Thanks for the read-through. Some responses inline! > > Best, > Tommy > >> On Jul 2, 2018, at 7:48 AM, David Bird <[email protected] >> <mailto:[email protected]>> wrote: >> >> Some comments (will not be at meeting) >> >> Section 1. The introduction states the purpose of the API as: >> >> o The state of captivity (whether or not the host has access to the >> Internet) >> >> o A URI that a host's browser can present to a user to get out of >> captivity >> >> o An encrypted connection (TLS for both the API and portal URI) >> >> The state of captivity is not all or nothing and being detailed about >> "captivity" (e.g. listing walled garden resources up front, down to >> protocol, port, hostnames, etc) will be complex and error prone. The URI for >> the captive portal can be gotten by RFC 7710. Captivity signaling should be >> granular; because we can, and it includes more use-cases. > > Agreed. The fundamental thing about this API draft is that it is not the > exhaustive set of information that the portal may want to communicate to the > UE. The example of the state being captive or not is a very simple case, and > there can certainly be more values to pass down. >> >> Section 2. The workflow is stated as: >> >> 1. Provisioning, in which a host discovers that a network has a >> captive portal, and learns the URI of the API server >> >> 2. API Server interaction, in which a host queries the state of the >> captive portal and retrieves the necessary information to get out >> of captivity >> >> 3. Enforcement, in which the enforcement device in the network >> blocks disallowed traffic, and sends ICMP messages to let hosts >> know they are blocked by the captive portal >> >> My issue is with the ordering... At step 2, we have Capport compliant >> devices enforcing themselves.. while non-Capport devices wait for the >> network enforcement. We have the (likely) scenarios of API server saying one >> thing (implying "self enforcement"), while the network "Enforcement" is >> telling the UE something else... who is right? Answer: always the network. > > This workflow is the summary of of the CAPPORT architecture document. I > completely agree that the enforcement is handled by the network, which is why > this is all in the third step. The API server does not imply enforcement—It's > the way for the portal that is doing enforcement to communicate information > to the UE. > > Non-CAPPORT devices currently do: > > 1. Provisioning, without knowing about captivity > - > 3. Enforcement via blocking and redirects, in which UE's need to guess what > happened > > The enforcement is always the network, but the UE can provide a better user > experience with 2. > > > > Do you envision CAPPORT devices doing 1, 2, and 3 before notifying the user > of captivity? Or, will CAPPORT devices just do 1 and 2 before notifying the > user (or attempting to "login")? It is the latter that I would call 'self > enforcement' because the client doesn't *know* there is captivity yet. >
Okay, I understand your point better now. You're right that until something goes wrong (3 blocks us) we don't truly *know* that we're captive and traffic will be blocked. However, I'd argue that this doesn't need to be the central point of the user experience going forward. Once the device has done 1 and 2, it can present the user with some UI with a login page, or other experience. All this guarantees to the device and the user is that they are on some network that provides a portal landing page experience. That landing page can describe what the contract of the network is—maybe it's totally captive, but maybe some services are allowed through without any extra login (like texting on airplanes, which I'm seeing these days). In the future, maybe some network won't even block traffic, but just use this landing page advertisement as a way to get some information to the user. As an OS vendor implementor, I view the responsibility of the OS as making sure the user sees the portal landing page if it exists, so as to allow the user to interact with the portal to remove captivity. Enforcement or making any guarantees about enforcement is not the job of the UE, it's the job of the network. The OS can choose whether or not to make a network it's default route for Internet traffic based on hints it has about captivity, as well as its experience of traffic working or not, but that's a reactionary step, not one of enforcement. Thanks, Tommy > >> >> Section 3.2. I think the JSON keys represent a too narrow view of walled >> gardens, and while simplicity is good, here it artificially and severely >> limits use-cases. >> >> Obviously, the "permitted" field is a boolean, not reflecting the fact the >> location very likely has freely available resources in the walled garden. >> >> The "expire-date" and "bytes-remaining" will be hard to synchronize with >> network enforcement... the enforcement function might not be counting *all* >> bytes (some might be "free"), session expiry could happen because of time >> and/or data limits - possibly being consumed by multiple concurrent >> devices/sessions - but also things like Idle Time or software restart (NAS / >> AP / etc) or a number of reasons. > > As mentioned above, this is just the basic set of minimal keys. It is > intended to be extendable as we flesh out the use cases. > >> >> What would be useful in the API, in my opinion, is for the API to provide a >> sort of validation, authentication, and additional information for and about >> network notifications. > > Yes, I agree! This was partly discussed at the last meeting; when we had the > HMAC key to validate network notifications, we decided to remove that until > we had further specified the use cases for validating the network > notifications. > >> >> On Sun, Jul 1, 2018 at 10:35 AM <[email protected] >> <mailto:[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 : Captive Portal API >> Authors : Tommy Pauly >> Darshak Thakore >> Filename : draft-ietf-capport-api-01.txt >> Pages : 7 >> Date : 2018-07-01 >> >> Abstract: >> This document describes an HTTP API that allows hosts to interact >> with a Captive Portal system. >> >> >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-ietf-capport-api/ >> <https://datatracker.ietf.org/doc/draft-ietf-capport-api/> >> >> There are also htmlized versions available at: >> https://tools.ietf.org/html/draft-ietf-capport-api-01 >> <https://tools.ietf.org/html/draft-ietf-capport-api-01> >> https://datatracker.ietf.org/doc/html/draft-ietf-capport-api-01 >> <https://datatracker.ietf.org/doc/html/draft-ietf-capport-api-01> >> >> A diff from the previous version is available at: >> https://www.ietf.org/rfcdiff?url2=draft-ietf-capport-api-01 >> <https://www.ietf.org/rfcdiff?url2=draft-ietf-capport-api-01> >> >> >> 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 >> <http://tools.ietf.org/>. >> >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ <ftp://ftp.ietf.org/internet-drafts/> >> >> _______________________________________________ >> Captive-portals mailing list >> [email protected] <mailto:[email protected]> >> https://www.ietf.org/mailman/listinfo/captive-portals >> <https://www.ietf.org/mailman/listinfo/captive-portals> >> _______________________________________________ >> Captive-portals mailing list >> [email protected] <mailto:[email protected]> >> https://www.ietf.org/mailman/listinfo/captive-portals >> <https://www.ietf.org/mailman/listinfo/captive-portals> > > _______________________________________________ > Captive-portals mailing list > [email protected] <mailto:[email protected]> > https://www.ietf.org/mailman/listinfo/captive-portals > <https://www.ietf.org/mailman/listinfo/captive-portals>
_______________________________________________ Captive-portals mailing list [email protected] https://www.ietf.org/mailman/listinfo/captive-portals
