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

Re: [Captive-portals] IPv6 RA URI option



Thats a clever way of doing it, that would solve the IPv6 issue as well.  

On Fri, Aug 26, 2016 at 2:47 PM, David Bird <[email protected]> wrote:
The DHCP option, once set, remains constant. The client learns the URL from DHCP Offer/ACK. 

For an example:

Client sends DHCP Discover/Request
NAS returns DHCP Offer/ACK containing:
   Assigned IP: 10.0.0.100
  Gateway IP: 10.0.0.1
  CAPPORT URI: http://10.0.0.1:3990/prelogin

[Chilli is the daemon responding to DHCP and is listening on 10.0.0.1:3990]

The client can issue a HTTP request to http://10.0.0.1:3990/prelogin and the NAS returns with a HTTP 302 redirect to something like https://my.domain/wifi?mac=... -- with session/station specific values.


On Fri, Aug 26, 2016 at 11:29 AM, Alexander Roscoe <[email protected]> wrote:
Hi David,

I am not too familiar with CoovaChili internals,  does the hijacking routine add the string params(station/session) to the DHCP option or is it scripted to use the option82 data and add the parameters after the user goes to http://<nas-ip>:<port>/prelogin?

On Fri, Aug 26, 2016 at 2:00 PM, David Bird <[email protected]> wrote:
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).



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-bounce[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





--
Alexander Roscoe




--
Alexander Roscoe
484-716-9048