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

["Joe Clarke (jclarke)" <[e-mail]>]

[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.

[JMC] I’m not suggesting multiple round-trips to the controller from the PEP per se.  I’m suggesting that the controller programs the PEP once with the resolved (i.e., 5-tuple) ACEs for a user upon login.  Essentially, this becomes a push model from controller to PEP.  If the user’s address changes, I am assuming a reauthentication would happen and programming would be redone.  In that case, it might make sense to have the user metadata as part of the model, so that the controller could do surgical reconfiguration of the PEP.  But having the PEP/device use the user-group details as a lookup point seems like it might be more impacting to performance than using the resolved 5-tuple data.

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.

[JMC] See above.  I want to make sure the packet flow is as unincumbered as possible while still allowing for this type of policy.

Joe