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:
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
>