[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Captive-portals] client identifying info between API and enforcement
I infer you mean the MAC address is required so that the portal can open/close the firewall using it as a filter.
I'd prefer to see this done at the Internet layer (AKA layer3), with IPv4/6 addresses, to avoid limiting usefulness to a particular access technology.
(a) one of the user's IP addresses would be used to make the request, but we might expect to include multiple addresses in the body of the request itself.
E.g., to provision IPv4 and (multiple) IPv6 at the same time.
Or, (b) we could say that provisioning must be repeated from each IP address to be used. Then the address could be implicit in the connection used for communication--which also serves as proof of ownership.
Just some thoughts.
From: Erik Kline [mailto:[email protected]]
Sent: Monday, October 16, 2017 8:20 AM
To: Kyle Larose; Dave Dolson
Cc: [email protected]; David Bird
Subject: client identifying info between API and enforcement
Kyle, Dave, (David, all,)
When a client is trying to talk to an [architecture-2.3] API server,
using the URL is learned in [architecture-2.2], will it need to
present some token that the API server can ultimately use when
communicating back to the enforcement box?
I'm effectively wondering about how we get (something like) the MAC
address of a client into this URL, /especially/ when the URL might not
be custom crafted for each client (i.e. in the case of the URL in an
ICMPv6 RA or learned via PvD mechanics).
What's required here and how do we think it should work?