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

[Remi NGUYEN VAN <[e-mail]>]

So to summarize, we've got a problem where the WLAN controller has some
rules to know who is blocked / allowed (probably based on mac address ?),
and can advertise a single API URL through DHCP / RAs / Link-Relation and
generate redirects, but does not have capabilities to serve login pages or
the API: this is handled by another box upstream which has more
capabilities like handling payment pages etc, and holds the SSL certs.
Because the API uses HTTPS (contrary to lots of login pages), the WLAN
controller can't easily insert identity of the requestor in the request and
the API has no way to know who it's replying to.

Since we can't advertise different addresses for different clients in RAs,
how about having the client add a session identifier in their API requests
? Having the client add a mac address in an HTTP request header field would
be a solution. Many devices are using random per-SSID mac addresses now, so
this sounds like a reasonable identifier for the device to give to the API
server (which could get it anyway through some complicated setup). It would
be possible for clients to make requests for API data of other clients
(assuming they know their mac address), but that's already possible by
spoofing the address anyway.

Cheers,

Remi


On Sat, Jul 27, 2019 at 8:04 AM Michael Richardson <[e-mail]>
wrote:

>
> Lorenzo Colitti <lorenzo=[e-mail]> wrote:
>     > Is there a problem with saying that the portal server should
> identify the
>     > device by IP address?
>
> Tommy Pauly <tpauly=[e-mail]> wrote:
>     > To that end, any enforcement of other traffic (such as normal web
> page
>     > loading) will not be carrying any session identifier, so only signals
>     > that are already present in the packets, such as the IP address, are
>     > effectively useful here.
>
> It's not obvious to me that you are talking about the same thing!
> The portal server *could* use IP address as the key by which to identify
> the device to the Captive Portal Enforcer.
>
> That requires that the access to the Captive Portal Server to always
> be on the same side of a NAT44 as the client, and I don't think that is
> realistic given how these services are outsourced.
>
> (In architecture-04, we have "Captive Portal Enforcement", which seems
> to be an activity, while the description is about a thing.  So I think
> that either the word "Point" should be added, or Enforcement->Enforcer)
>
> The Captive Portal Enforcer SHOULD enable traffic based upon the mapped
> L2 address, otherwise, there would have to be a new portal session for
> IPv4 and IPv6, and for each new IPv6 temporary/privacy address.
> I don't think we want that.  It would also, I think, force the portal
> server to speak both v4 and v6.
>
> The communication between Captive Portal Server and Captive Portal Enforcer
> COULD identify the client by L3 address, but I wouldn't want to build
> things
> that way, because it would result in a poor experience for returning users,
> such as sleepy phones, or hotel guests that might leave the hotel and then
> return later in the day, and expect their 24hr pass to just work, despite
> DHCP leases being much shorter.
>
> --
> Michael Richardson <[e-mail]>, Sandelman Software Works
>  -= IPv6 IoT consulting =-
>
>
>
> _______________________________________________
> Captive-portals mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/captive-portals
>