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

Re: [Captive-portals] I-D Action: draft-ietf-capport-api-01.txt



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.

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.

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

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.

On Sun, Jul 1, 2018 at 10:35 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           : 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/

There are also htmlized versions available at:
https://tools.ietf.org/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


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