Hi, Joe Thanks for your review and valuable comments. Please see my reply inline. From: Joe Clarke (jclarke) [mailto:[email protected]] Sent: Tuesday, November 29, 2022 3:42 AM To: [email protected] Cc: [email protected] Subject: Review of draft-ma-opsawg-ucl-acl
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. While it might seem natural to allow the controller to determine the user-group based access right and configure the IP/MAC details to the network devices, this work focuses on the enterprise network scenario where mobile office is quite normal. Such a mobility across different access locations causes the frequent changes of the IP addresses, thus the controller needs to interact with the device frequently to adapt to the changes of users IP addresses. Frequent interaction between controller and network devices would also result in the high performance cost. Thus our motivation is to decouple the user identity from the network addresses. The controller configures the user-group based ACL policies no matter how the users' network addresses vary. Does this make sense? 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? The current ietf-ucl-group model tries to build the mapping between the user-group ID and the user's associated attributes. The role is defined as a mandatory-false node, I think that this node might be useful when administrators would like to understand the user-group information. A single group-id would be useful to uniquely identify a user-group, while a role-type provides an overview of what that user-group ID represents. 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. Well, this information is exactly maintained on the network controller, rather than the devices. It is the user-group extension to the ACL model that should be implemented by the network devices/PEP (the draft has defined two models). Postal-code tries to capture the users access locations, in some cases the a user might belong to different user-groups (and be granted different access permissions) if the access location is different. Anyway, the authors admit that the current definition of both models might be insufficient, thanks for pointing this out. Joe Best Regards, Qiufang
_______________________________________________ OPSAWG mailing list [email protected] https://www.ietf.org/mailman/listinfo/opsawg
