Hello WG and authors. I promised/threatened a review of this document during opsawg after I had a chance to take a deeper look. I appreciate the presentation both in netmod and in opsawg. Below are some contributor thoughts.
But after a deeper read, I’m perhaps a bit more confused. Ultimately, I see value in this concept of this work. Where I struggle is on the applicability. That is, I think your presentation showed that this model would be implemented on a network element/device. However, I would think that look ups to translate policy elements to actual [dynamic] endpoints would be expensive. That is, if the PEP is the device, performing the mapping of incoming packets to the associated user and group IDs sounds like a non-starter where performance is concerned. If the PEP was the controller/orchestrator and it mapped the user to its group, then it could push the IP/MAC details down to the end devices (and expire those ACEs after the given time). This changes the flow to be sure, but it feels more natural at least in my head. It seems to me the flow might be: Step 1: Administrators configure the controller/orchestrator with the security policies (e.g., group Finance can access Finance resources) Step 2: The user-group-based access control is maintained on the controller (this is now the PEP, I guess) Step 3: A user logs in Step 4: The AAA server either notifies the controller or the device notifies the controller that user jdoe has logged in successfully with the given group attributes Step 5: The controller programs the NAS with the required IP/MAC ACEs On the model itself, I don’t understand the intent of role-type. I guess it’s so you could say user’s with a role of visitor can only access visitor resources? But couldn’t you do that with arbitrary groups and not have to list out various identities? Enforcing certain localities in the network makes sense (i.e., using geo location for IPs). But postal code is interesting. You won’t really know this for a mobile user. Again, this information seems too high level to be on a device. It might fit better on a controller that knows the network and where services are located. Joe
_______________________________________________ OPSAWG mailing list [email protected] https://www.ietf.org/mailman/listinfo/opsawg
