Sorry for late follow up. Thank you very much for the valuable comments, they have been incorporated into the -01 version (https://www.ietf.org/archive/id/draft-ma-opsawg-ucl-acl-01.txt). And the steps have also been updated as you proposed accordingly.
[JMC] Thanks. As stated, this flow seems more generally doable (at least in my head). While a subtle difference from what you’ve proposed is that, the current draft defines the group-based ACL YANG module without limiting how it can be used. Instead of simply stating that the controller will translate group information into required IP/MAC address and delivers address-based ACEs to the PEP devices, the draft also allows the device to perform UCL based policy if it can understand the group information. E.g., if a group identity could be carried in the packet header[1]. [JMC] That seems reasonable. I do agree with you that looking up the mapping info on each PEP is expensive and has performance issue, but in above case I think it might be okay to allow the device to perform group-based ACL. Thus the step 5 in the current document: Either group or IP/MAC address based access control policies are maintained on relevant PEPs under the controller's management. Does this make sense from your perspective? [JMC] This flexibility does make sense. That said, now it seems that the augmentations in this draft could apply both to the SDN controller and the PEP, correct? I get the former as part of the new Step 1. But the latter wasn’t clear to me in Step 5. Ultimately, I think an example of both cases (MAC/IP and group) could be helpful along with some additional text to indicate what type of ACL config may exist on the PEP. [JMC] Additionally, a few comments: What is iSchedule? I see one reference to it, and it is not explained (in the new schedule YANG module). I would add values to the days of the week (perhaps use the same numeric values as cron). Why is bysecond 0..60 whereas byminute 0..59. I would think both would be 0..59. Ultimately, this draft yearns for examples, especially of this schedule mechanism which, while more complete than the initial draft, brings a lot of complexity. Joe [1] https://datatracker.ietf.org/doc/draft-ietf-nvo3-encap/ see sec.6.2.3 Best Regards, Qiufang From: Joe Clarke (jclarke) [mailto:[email protected]] Sent: Friday, December 2, 2022 1:26 AM To: maqiufang (A) <[email protected]>; [email protected] Cc: [email protected] Subject: Re: Review of draft-ma-opsawg-ucl-acl [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
_______________________________________________ OPSAWG mailing list [email protected] https://www.ietf.org/mailman/listinfo/opsawg
