Hi, Joe Apologize for being late with this response.
Please first allow me to give more context about this specific question, I recall presenting the next step of this work in IETF 117, to add application-group as the third endpoint group (beside user-group and device-group), the authors believe this could be useful if multiple applications that need to apply different access control policies run on a single device. That way would require the controller or the PEP performing the application-group based ACL to understand the mapping between the application-group and the packet fields(e.g., IP and port). I am thinking it to be optional to implement. I cannot really remember having mentioned that some advanced method like DPI must be there to effectively implement this application-group based ACL;-) In fact, I am now thinking the easiest way like statically configuring the mapping between the application-group and packet fields would work. And I would share the idea with you that this work should be able to be used even without any additional capabilities. Hopefully this clarifies things to you. Best Regards, Qiufang From: OPSAWG <[email protected]> On Behalf Of Joe Clarke (jclarke) Sent: Thursday, September 7, 2023 7:01 PM To: Tianran Zhou <[email protected]>; [email protected] Cc: [email protected] Subject: Re: [OPSAWG] Working group adoption call for draft-ma-opsawg-ucl-acl-03 As a contributor, I support adoption of this work. I have previously read and commented on this document. The main reason for my comment this time is to address something that was brought up at the mic in 117. There was a question asked about needing deep packet inspection to effectively implement this. Quifang said yes, but I don't think it would be necessary. If the controller maintained the state and knew who the user was through other means (e.g., AAA/dot1x), it could program the network elements with standard ACL tuple data (i.e., traditional ACLs) dynamically, thus not putting more logic onto the devices or into the hardware. This was similar to a past comment of mine, and I think the document text addresses this. It's not to say an implementor couldn't do something fancier within the network, but I don't think additional capabilities are required to make this work. Joe ________________________________ From: Tianran Zhou <[email protected]<mailto:[email protected]>> Sent: Monday, September 4, 2023 9:12 PM To: [email protected]<mailto:[email protected]> <[email protected]<mailto:[email protected]>> Cc: [email protected]<mailto:[email protected]> <[email protected]<mailto:[email protected]>> Subject: Working group adoption call for draft-ma-opsawg-ucl-acl-03 Hi WG, This mail starts a two weeks working group adoption call for draft-ma-opsawg-ucl-acl-03 https://datatracker.ietf.org/doc/draft-ma-opsawg-ucl-acl/ Please send over your objections or supports to the mailing list. If you object the adoption, please also give the reason, so that the authors can improve. We will conclude this adoption call on Sep 20, 2023. All your comments are welcome. Best, Tianran
_______________________________________________ OPSAWG mailing list [email protected] https://www.ietf.org/mailman/listinfo/opsawg
