Erik Kline <e...@google.com> wrote:
>> 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).
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.
> 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?
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 <mcr+i...@sandelman.ca>, Sandelman Software Works
-= IPv6 IoT consulting =-
signature.asc
Description: PGP signature
_______________________________________________ Captive-portals mailing list Captive-portals@ietf.org https://www.ietf.org/mailman/listinfo/captive-portals
