Hi, Michael Thank you for the comments, see inline with [Qiufang]. > [1] https://datatracker.ietf.org/doc/draft-ietf-nvo3-encap/ see sec.6.2.3 As I understand NVO3 (and GENEVE), it is an encapsulation layer that runs on top of UDP layers and can carry ethernet packets. (I've deployed a few of these things)
But, in this context, I'm unclear if the UCL-ACL would apply to the outer IP/UDP header or to the inner one. [Qiufang] If it is group-id that is to be matched, the UCL-ACL policy would apply to the outer NVO3 header (e.g., VXLAN header) which carries a source group identifier. If there were reasons to apply rules to the inner one, wouldn't it make more sense to have a PEP at the NVO3 encapsulation point? If it would make sense to apply rules to the outer one, would it be easier to just have more than one tunnel? [Qiufang] I am not sure I've fully understand your points. But consider the scenario where users A (in group 1) and B (in group 2) communicate with each other in two different enterprise branches. The PEPs could locate at the network ingress (NAS) of both branches, each has only the ID-to-address mapping of their respective authenticated user. Suppose a VXLAN tunnel is established between two network ingresses with the source group ID carried in the VXLAN header and sent to the destination user. The destination NAS decapsulates VXLAN packets and obtains the source group ID and then performs group-based ACL polices based on that. While another implementation could be that, the controller that has both group A and group B mapping info just delivers the IP/MAC address-based ACL policies to both PEPs, if no encapsulation is used. Hopefully this clarifies. Michael Richardson <[email protected]> . o O ( IPv6 IøT consulting ) Sandelman Software Works Inc, Ottawa and Worldwide Best Regards, Qiufang _______________________________________________ OPSAWG mailing list [email protected] https://www.ietf.org/mailman/listinfo/opsawg
