This is a bit of a stream of consciousness, so sorry if I ramble. :) Dave: There's also actions such as querying the state of captivity we need to consider.
Regarding the main question: Does it make sense to have the query be in two steps, or would that too complicated? E.g. if the API could indicate to the user that a particular piece of information was required -- MAC vs IP vs something else -- then it could be useful. In the hackathon at IETF 98, the API worked in a few steps. The User Agent would do a get on the URL, which would tell it where to create its session. It would then create a session with its MAC. That returned a session ID which was used for further communication. If the session already existed, the create would just return the same info as before. It worked pretty well, but the enforcement device was on the same segment as the user equipment. Now, I'm not saying this is what we want to do here, since if the API is read only, we may not want to look at creating sessions. But, if the first get could return one of "Give me your MAC address, or give me your IP, or ...." then would that be sufficient? Or, are we concerned about the security of this? For example, I could just query random IPs on the network to see who is connected/active. If we had a randomized integer, it may be a little more secure. But, if it's a random integer, presumably it's handed out by the enforcement device or provisioning service. And that comes to your point about the URL not being per client. Would it be possible to include an extra field in the RA/PvD mechanics to hold this information? (I need to read up more on both of these, admittedly, so I'm probably missing something here). Do we need to worry about things like NAT, here, or should we call that out of scope? I'm thinking about my laptop behind some sort of portable router point querying the status of the captive portal to which that portable router is connected. -----Original Message----- From: Dave Dolson Sent: Monday, October 16, 2017 10:24 AM To: Erik Kline; Kyle Larose Cc: [email protected]; David Bird Subject: RE: client identifying info between API and enforcement Erik, 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. So then, (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. -Dave -----Original Message----- 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 <hat-free /> 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? _______________________________________________ Captive-portals mailing list [email protected] https://www.ietf.org/mailman/listinfo/captive-portals
