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

Re: [Captive-portals] Arguments against (any) Capport "API"

  I was just refreshing my memory on the WISPr spec and I agree with all of your points.

  I would add that WISPr is a very rigid protocol with a very specific flow and intention.

  Because of these shortcomings, I would leave the option of an API on the table - particularly with a nod to the lessons that we can learn from WISPr and it's implementations.

Cheers!

Christian

On 17-04-05 11:45 AM, David Bird wrote:
There are problems with WISPr, one being that it has somewhat ambiguous copyrights, which is why you will not find it easily on-line.

It was proposed by WFA, but never ratified. With that said, there are some lessons to be learned from it:

- It probably would be good to have something with cleaner specifications, but adoption by the long-tail hotspot operators could be slow (even slower thank upgrading NAS capabilities). Critical to vendor/venue adaption will be roaming aggregator adoption, and you have the chick and egg problem.

- WISPr XML wasn't overly complicated, but it being implemented by all sorts of portals, in all sorts of ways, gave it a very bad reputation as being broken. (A fear I have for our API as well.)

- WISPr only defined, basically, a Username / Password login method, which fits AAA/RADIUS models, and the industry has largely adapted to (for instance, it is common to do 'Mac Auth' using a shared 'Password' field or to fit voucher codes into a username/password combinations). 




On Wed, Apr 5, 2017 at 10:30 AM, Christian Saunders <[email protected]> wrote:
Does WISPr support all of the use cases?  Is there a publicly available source for the WISPr XML spec?

Cheers!

Christian


On 17-04-05 11:15 AM, David Bird wrote:
I agree with that... but, to be clear, it really is just an improvement on WISPr XML, and with WISPr XML already, not only used, but used to make money, the reasons for supporting this API MUST be inline with the venue/Operator needs. 'Automating login' (as a focus for the API) quickly becomes venue / regional / legal / vertical / application / access policy dependent.. Not to mention, I question the value for the user in making it super simple for their devices to auto-login into public access networks (without clear user intent). This seems irresponsible, on our part, when there are solutions out there already that do automate this login, but only after taking extra security measures (presumably, hotspot aggregators conceal your identity when roaming, and their Apps can do more things).

On Wed, Apr 5, 2017 at 9:51 AM, Dave Dolson <[email protected]> wrote:

This is OK if you only need to serve devices with browsers and attentive humans.

The API offers possibilities for automation in the device by making a formal data model (vs. HTML).

 

 

From: Captive-portals [mailto:captive-portals-bounce[email protected]] On Behalf Of Christian Saunders
Sent: Wednesday, April 5, 2017 12:38 PM
To: David Bird
Cc: [email protected]
Subject: Re: [Captive-portals] Arguments against (any) Capport "API"

 

The currently proposed solution has 3 components:



1. The ICMP component is used to detect a captive network.

2. The DHCP component is used to discover the address of the Captive Portal.

3. The API is an information service with a standardized interface that allows discovery and potentially remediation of the requirements for network access.

The ICMP and DHCP components are sufficient to resolve the redirection and HTTPS issue.

I would consider the API as an optional component - it might create some user experience benefits if the device developers and network operators choose to use it.

The difficulty with the API is having a way of codifying all of the possible network access requirements.  I'm not sure this is reasonably possible.

Assuming that such a definition is possible, then there is some benefit to the common definition.

(It also strikes me that this definition would make a nice back end design for the Captive Portal itself.)

Cheers!

Christian 
 

On 17-04-05 10:25 AM, David Bird wrote:

Edits in-line :)

 

On Wed, Apr 5, 2017 at 9:06 AM, David Bird <[email protected]> wrote:

A few more key benefits of the ICMP approach :

 

- Capport detection is made easier for the client, even when RFC 7710 (or any API) is NOT implemented (as long as the NAS is Capport compliant).

 

- "Signaling" can be done by different components (NAS, iptables, rate-limiter, PCEF, etc), without (necessarily) needing to coordinate with a central service.

 

- In defining the RFC in how a NAS should handle blocking traffic for Capport compliant devices, we are also defining how the NAS should handle Legacy devices - which is, there is no difference - they both get ICMP Dest Unreach w/Capport extension) - which is helpful.

 

 

 




_______________________________________________
Captive-portals mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/captive-portals