Re: [OPSAWG] Review of draft-ma-opsawg-ucl-acl

["maqiufang (A)" <[e-mail]>]

Hi, Joe,

[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.
I think I have no doubt that the controller needs to maintain a high-level user-group based ACL, the divergence between us is that whether it has merits to allow devices to be aware of user-group.
I agree with you that the current draft would need devices to resolve common network header (e.g., 5 tuple) to user-group ID at packet level, and then look up the related user-group based ACL; but this way the controller only needs to pre-configure the devices once (at least the least number of times) and the user-group based ACL itself can dynamically adapt to different circumstances(e.g., IP/MAC changes, time varies, etc).

I also agree that it feels more straightforward if the devices can only see the common network header attributes and look up ACL directly, but it does requires multiple communications between the controller and the device, depending on the user group attribute changes.

It seems to me that both have upsides and downsides.
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
In your proposed flow, are you suggesting that the controller programs the NAS dynamically according to the network header (IP/MAC) information notified by the AAA server or the device? Does the "device" you mentioned in step 4 refer to the user authentication device/AAA client which has received the authentication result feedback? Just want to ensure that I've fully understood your proposal.

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.
Sure, will update the data type in the next version. Thanks;-)
Joe

Best Regards,
Qiufang