Re: [Captive-portals] Review of draft-ietf-capport-rfc7710bis

[David Bird <dbird@google.com>]

Expanding on that Cisco example for a minute....

How would Cisco implement 7710bis and API? 

It would make sense for Cisco to implement the API server directly into their WLAN controller... In that case, it probably could use the same URL for the API server for all subscribers (and be in a position to uniquely identify the session and lookup internally its state).  [As I've argued before, the NAS/WLC is the *right* place for capport notification - or API - mechanism because it is the ultimate source of truth for the state of the session -- it is, after all, the one doing the enforcement].

However,  who would own the API SSL cert? Often times, the "hotspot services company" isn't the owner of the WLAN Controller. Ideally, the venue is buying their own certs and installing them in their own gear.. but, is that what will happen in practice? I could also imagine that hotspot services companies will see the API an extension of their service and want to control it... so, my question is, how will vendors implement this? 

On Thu, Jul 25, 2019 at 5:56 AM David Bird <dbird@google.com> wrote:

Hi Martin,

The "this" refers to uniquely identifying the UE/session. The API server will need to "lookup" the UE/session in some way (like in a database shared with AAA) to get its state (captive or not, how much time/data remaining, etc). In this regard, the API and the Captive Portal itself *both* need this ability to uniquely identify the UE/session.

Sure, one *could* design an API server, to reside on the same L2 segment as the subscribers, so that it can determine the UE mac address from looking up the remote IP address in the local ARP table. But... in practice, I think the tendency would be to host the API in the same centralized place as the captive portal itself (and share the same database). 

In terms of generating a "session-id" ... a lot of this is very implementation dependent. For example, many hotspot systems are integrated with DHCP/RA because the IP address of subscribers may come from AAA (or a PGW in 3gpp). The redirection URL is often "minted" with the right session_id for that session by the backend AAA/PCRF. 

Here is one example:

https://www.cisco.com/c/en/us/td/docs/wireless/controller/7-5/configuration-guide/b_cg75/b_cg75_chapter_01011101.pdf

On Thu, Jul 25, 2019 at 4:31 AM Martin Thomson <mt@lowentropy.net> wrote:

Hi David,

On Mon, Jul 22, 2019, at 19:40, David Bird wrote:
> ultimately a "session-id" is
> typically carried in the redirect URL on a per UE/session basis. If
> everyone gets the exact same URL, this can only be done by IP address
> at the portal... Is that the design networks are encouraged to take?

I'm not following your "this" here.  Can you say more?

I understand that a session ID is needed, but is this something that can be inserted on the transition from the API endpoint to the web page?

_______________________________________________
Captive-portals mailing list
Captive-portals@ietf.org
https://www.ietf.org/mailman/listinfo/captive-portals