Is another way of looking at this problem to consider defining the identity of the user equipment?
>From the perspective of the enforcement device, it's probably the source MAC >address or source IP (or both) of the packets being sent through it. It's hard >to spoof that without wrecking the network, right? But, if we intend on having the API server potentially live elsewhere in the network, those identifying characteristics may not be available in the requests being sent to that server, or if they are, they may be different due to intermediate devices such as NAT, routers, etc. If the user equipment understands its identity, then it can always put that into requests. As long as everyone agrees on what constitutes the identify, we're good. That sort of aligns with my earlier email about potentially negotiating what identifies a user equipment. However, what concerns me with this approach is security: how can we trust that the client of the API server isn't spoofing its identity? So, the question becomes: what verifiable identify can a user equipment have that an API server can validate, and if necessary, translate into an identity understood by the enforcement device? -----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
