Re: [Captive-portals] IPv6 RA URI option

RFC 7710 says, ".. provides the URI to access an authentication page." Obviously, this will need further clarification should it point to an API end-point. As it is written, I think it is clear that the URI should be the same (or will redirect you to the same) URL as a HTTP hijack takes you to (minus any "original URL").

In CoovaChilli, at least, there is already an internal/local URL that is suitable for RFC7710. In that the URL http://<nas-ip>:<port>/prelogin in chilli hooks into the hijacking routine to redirect the user to the captive portal URL specific to them (e.g. the hijacking routine adds the query string params specific to station/session).

https://github.com/coova/coova-chilli/pull/274/commits/1e95a2cf97e981f2f53826e38cd12372555a809c

On Fri, Aug 26, 2016 at 10:08 AM, Dave Dolson <[email protected]> wrote:

Alexander,

Suppose instead of providing a URL for the landing page, the RA provided the URI for a standardized REST interface; the client could post its details (MAC address, device type?) to this interface, which would return the URL for the browser landing page, and possibly any number of other details and mechanisms, e.g., in a JSON response.

This adds a level of indirection that simplifies what needs to go in the RA.

I think there is also flexibility in letting the client know details about the capport situation in the API. E.g., how often will the page need to be visited?

RA-->client: “This is the URI for getting capport info: http://capport.example.com/api”

Client-->capport/api: “My MAC address is 01:02:03:04:05:06 and my IP address is …”

Capport/api-->client: “Your landing page is https://capport.example.com/landing/mac=01:02:03:04:05:06 ; refresh every 60min”

-Dave

From: Captive-portals [mailto:captive-portals-[email protected]] On Behalf Of Alexander Roscoe
Sent: Friday, August 26, 2016 11:15 AM
To: [email protected]
Subject: [Captive-portals] IPv6 RA URI option

I am looking over RFC 7710 concerning how the URI is communicated to the end user. I really like the IPv4 DHCP solution, I think this could easily be implemented in a DHCP server. I think it could be easily implemented in the RA for IPv6 as well however I do see a challenge when each connected client needs a unique URI such as it containing the parameter for the client mac. For example, a url like https://captiveportal/?client-mac=11:22:33:44:55:66. The RA is sent to everyone and cannot be tailored to each client while DHCP is very client specific and can be changed on-the-fly. Most captive portals rely on the client mac address during the authentication process. I am aware of networks using the IP address to associate the user at the AAA server but from my understanding this is a rare network setup. I think a potential solution for the IPv6 RA would be to define an HTTP POST parameter in which the client can use like ‘client-mac’ and let the client post it the URI https://captiveporta/. Thoughts? Ideas?

--
Alexander Roscoe
484-716-9048

_______________________________________________
Captive-portals mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/captive-portals