Subject: [Captive-portals] IPv6 RA URI option

From: Alexander Roscoe <[email-masked]>
Date: Fri, 26 Aug 2016 11:14:53 -0400

I am looking over RFC 7710 <https://tools.ietf.org/html/rfc7710> 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

---

From: Dave Dolson <[email-masked]>
Date: Fri, 26 Aug 2016 17:08:55 +0000

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:[email-masked]] On Behalf Of Alexander Roscoe
Sent: Friday, August 26, 2016 11:15 AM
To: [email-masked]
Subject: [Captive-portals] IPv6 RA URI option

I am looking over RFC 7710<https://tools.ietf.org/html/rfc7710> 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

---

From: David Bird <[email-masked]>
Date: Fri, 26 Aug 2016 11:00:21 -0700

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-masked]> 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.
>
>
>
> 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?
>
>
>
> 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:[email-masked]] *On
> Behalf Of *Alexander Roscoe
> *Sent:* Friday, August 26, 2016 11:15 AM
> *To:* [email-masked]
> *Subject:* [Captive-portals] IPv6 RA URI option
>
>
>
> I am looking over RFC 7710 <https://tools.ietf.org/html/rfc7710>
> 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
> _______________________________________________
> Captive-portals mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/captive-portals
>
>

---

From: Alexander Roscoe <[email-masked]>
Date: Fri, 26 Aug 2016 14:29:07 -0400

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-masked]> wrote:

>> 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?
>>
>>
>>
>> Capport/api-->client: “Your landing page is
>> https://capport.example.com/landing/mac=01:02:03:04:05:06 ; refresh
>> every 60min”
>>
>>
>>
>>
>>
>>
>>
>> -Dave
>>
>>
>>
>>
>>

-- 
Alexander Roscoe
484-716-9048

---

From: David Bird <[email-masked]>
Date: Fri, 26 Aug 2016 11:47:09 -0700

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-masked]> wrote:

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

---

From: Alexander Roscoe <[email-masked]>
Date: Fri, 26 Aug 2016 15:16:22 -0400

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-masked]> wrote:

> The DHCP option, once set, remains constant. The client learns the URL
> from DHCP Offer/ACK.
>
> For an example:
>
>>> 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).
>>>
>>>> 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.
>>>>
>>>>
>>>>

-- 
Alexander Roscoe
484-716-9048