Subject: Re: [Captive-portals] Questions about PvD/API

From: Erik Kline <[email-masked]>
Date: Wed, 27 Sep 2017 15:44:12 +0900

> 5.1.1.  Associating User Equipment with its URL
>
>    The CAPPORT API Server SHOULD associate an incoming request with a
>    particular User Equipment consistently.  [TODO: specify how this
>    would happen.]
>
> This becomes a pretty important point because it can't be that each DHCP or
> RA is custom formatted for each station with a UE specific URL. It also
> needs to be a MUST if the API is returning information about
> 'bytes_remaining' and such. Or, does the UE self report it's MAC to the
> API/PvD? The service needs some way of associating that API/PvD session with
> the RADIUS accounting stream.

<no chair hat>

This is a very critical question, imho.

No captive portal vendor would want to trust clients to self-identify
their MAC addresses.  And even non-malicious clients might be prone to
introducing errors (say, by presenting the random MAC used during
scanning and not [as a result of a bug] the actual MAC used for the
session).

Given that, it seems the network infrastructure itself must be the
element that adds MAC addresses, or some equivalent token, in
communications with the API endpoint.  Yes?

---

From: Erik Kline <[email-masked]>
Date: Wed, 27 Sep 2017 15:53:25 +0900

On 31 August 2017 at 22:04, David Bird <[email-masked]> wrote:
> I will add Vincent's (valid) concern about API/PvD: It requires either
> polling or push (over TCP, which does require keepalive for NAT traversal),
> which means stations likely do not go idle on the network, and, in cases
> where a captive portal is possible, but not probable, UEs still have to
> maintain this API/PvD association if they want to ever get notified.

<no hats>

This is a limitation of the current PvD proposal: it's rather
DHCPv6-like in that it lacks a mechanism to inform either all clients
or even a single client of a change in state.

It would be possible to notify all clients of a change in
non-client-specific PvD information by, for example, including a "pvd
generation number" in RAs.  The "ISP is captive portaling you because
you're infected" case can be handled by any such all-clients
notification scheme (e.g. pvd gen ids).  This is because the
architecture as described disconnects and reconnects the home network
and (I presume) every single device in the home is effectively and
equally captive.

But for individual clients, a push notification system for PvD state
changes is not yet immediately obvious to me.  For the specific case
of notifying captive state changes to clients I'm still hoping we can
use your ICMP portal notification option.

---

From: Michael Richardson <[email-masked]>
Date: Wed, 27 Sep 2017 11:50:58 -0400

> scanning and not [as a result of a bug] the actual MAC used for the

Not only do we have a problem with the clients presenting the wrong MAC by
accident, they could also present the wrong MAC on purpose to gain
information about adjacent clients. A simple multiple PING harvests that
list.

    > communications with the API endpoint.  Yes?

It must provide a token based upon the MAC, but I think it must protect it as well.

In only the simplest cases will the portal/API receiver be on the same link
as the client, so even though we can get the MAC address via DHCP relay, the
portal can't verify the address is the correct one accessing it anyway.

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-