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

["Martin Thomson" <[e-mail]>]

This is one of the costs of this architecture.  If the external system (portal HTML, etc...) needs access to identifiers, then the API endpoint will have to decorate the URLs it provides.  That might mean having the API endpoint inside the network, where it can see source IP or BSSID or whatever is being used for identification.  

An external service won't be able to validate any identifier it receives in this way, so you might want to make the decoration a little more complex than a simple addition of `?ip=192.0.2.3`.  Of course, the worst I can think of (offhand) is that someone could pay for my network access.

On Mon, Jul 29, 2019, at 13:51, Remi NGUYEN VAN wrote:
> 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] <mailto:[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] <mailto:[e-mail]>>, Sandelman Software Works
> >  -= IPv6 IoT consulting =-
> > 
> > 
> > 
> >  _______________________________________________
> >  Captive-portals mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/captive-portals
> _______________________________________________
> Captive-portals mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/captive-portals
> 
> Attachments:
> * smime.p7s