Thanks for the reply. See below. 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?
[JMC] It makes sense conceptually. In practice, though, it seems very inefficient for the NAS to be resolving the user-group assignments at the packet level (the draft mentions something to this effect). You’re right that resolving that at the controller level wouldn’t be any more practical. But what I envision is that the mapping of session (i.e., user-group) attributes to network header elements (i.e., MAC/IP) would happen once and be generally visible to the administrators of the network. The ACEs on the device need not have explicit user-group properties. Those could be comments. For example (in CLI syntax): ip access-list extended DYNAMIC-ACCESS 10 comment Allow jdoe to access finance resources 20 permit ip host 10.10.10.10 172.20.20.0/24 … This way the device isn’t have to resolve any of the user-group elements on reception of a packet. The controller, on the other hand, would have a broader picture of the network use and access. It would show where the user connected, when, and their session properties. 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. [JMC] Seems like that could just be a description (string) rather than having to maintain arbitrary identities. Joe
_______________________________________________ OPSAWG mailing list [email protected] https://www.ietf.org/mailman/listinfo/opsawg
