Hi, > On 11 Jul 2017, at 07:43, Ehsan Shahrokhi <ehsan...@gmail.com> wrote: > > Hi, > > >Why tie together two plugins with potentially very different use cases ? > > I didn't mean to tie these two plugins together. I just have this in mind > that both these plugins have common function of connection tracking. For > example, why they do not use the one common code for this functionality? > Appearently there was a reason not to do so. May you describe that? In fact I > have no idea about their different use cases. Because this part of connection > tracking and taking record of connections seem to be common, even management > of connections.
The plugins were developed independently so that's one part of the reason why it's not a common code. Also, having common code means having it somewhere - would it be in snat or acl plugin ? The session-related code in acl plugin is about 50 lines out of about 3000 - so there would not be a lot of win to keep them together and whole lot of logistical overhead. If the time shows that these two modules are used together a lot and joining the connection tracking is of value, of course or can change in the future! > > >The mental model of acl-plugin is small per-interface "firewall", > >independent from other interfaces. > > Do you have any plan to extend this per-interface firewall to have this > stateful functionality over multiple interfaces(the other interfaces I mean)? Not at the moment - since the multi-firewall model seems to be quite simple and potentially accommodate a set of any features (say you have IPv4 on the inside and IPv6 on the outside, and nat64 inbetween) and works. At some point there was an idea to have a flag on the packet "acl check was successful, please create the return connection", it would take care of most situations not involving the dynamic routing. Could you tell a bit more about the scenario you are looking for ? --a > > Regards, > Ehsan Shahrokhi > >> On Sun, Jul 9, 2017 at 10:14 PM, Andrew Yourtchenko <ayour...@gmail.com> >> wrote: >> >> >> > On 9 Jul 2017, at 07:31, Ehsan Shahrokhi <ehsan...@gmail.com> wrote: >> > >> > Hi, >> > >> > I have two questions about stateful. >> > First, why stateful implementation of NAT and ACL are independent? Was >> > there any logic behind this? As it is expected that both ACL and NAT >> > plugins use the same connection tracking code base or platform. >> >> Why tie together two plugins with potentially very different use cases ? >> >> > >> > Second, Should we define an acl in both directions even if we are >> > configuring stateful acl using "permit+reflect"? Or if I have a >> > "permit+reflect" acl in one direction, can I expect the response packets >> > to be also permitted? >> >> The mental model of acl-plugin is small per-interface "firewall", >> independent from other interfaces. >> >> If you don't have an acl applied, then the packers are permitted. >> >> From this - if you want a firewall like behavior on an interface, you need >> permit+reflect in one direction, and deny in the other direction on that >> interface. >> >> If you only have permit+reflect on one interface and no acl in the other >> direction, it will still work by for a different reason. >> >> --a >> >> > >> > Regards, >> > _______________________________________________ >> > vpp-dev mailing list >> > vpp-dev@lists.fd.io >> > https://lists.fd.io/mailman/listinfo/vpp-dev >
_______________________________________________ vpp-dev mailing list vpp-dev@lists.fd.io https://lists.fd.io/mailman/listinfo/vpp-dev
