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

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

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:

On Thu, Jul 25, 2019 at 4:31 AM Martin Thomson <[email protected]> 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
[email protected]