My two cents: > >I did evaluate both the options of using current network ACL > >functionality to implement the egress firewall rules and enhance > >CreateFirewall API to support both ingress and egress. If we go down the > >path of implementing egress firewall with Network ACL it increases the > >scope of the proposed changes to make behaviour consistent across APIs. > > > >1. First network ACL's implementation is hardcoded for VPC only.Network > >ACL's implementation will have to be generalised first to support both > >virtual router and VPC virtual router, and make it work for both VPC > >networks and non-VPC networks. > > Easy to change. Just make VirtualNetworkRouterElement to implement > NetworkACLServiceProvider. And move networkACL code from > VpcVirtualRouterManager to virtualRouterManager. >
The spec also talks above extending this behaviour to SRX and other shared devices across tenants in a zone. That would also have to be factored in. Also, wouldn't this effectively mean we are deprecating the VR as an element? So in the future all VRs are necessarily VPC VRs? If yes - I didn't see a discussion on this when VPC networking was done. Time for one now? > > >2. Also currently while creating network offering, firewall and network > >ACL's services are mutually exclusive which tells me that the purpose of > >each is different. > > Artificial limitation. There is nothing on the backend preventing from > applying network ACL and Firewall rules. As a part of the fix for that, > add capability "trafficType" to the NetworkACL service. Regular VR will > support Public capability (as you create the network ACL for public > network only); in VPC is going to be Guest. > > > > We need to understand how network ACL rules are different from Firewall > >rules. The difference comes about when you look at the > >stateful/stateless nature of traffic being shaped by the router. In most > >networking parlance I have seen, network ACLs serve only stateless > >behaviour. Firewalls can do stateful traffic filtering - ingress and > >egress. > > > Anthony Xu can help you to understand how its different as he did the > scripting for the network ACL calls on the virtualRouter. > Anthony - what is the current behaviour of network ACLs? Are they processed one by one until a best rule is matched? Or all rules looked at before taking a filtering decision? I'm just preparing a setup to test this. > > >3. My final concern is the confusion coming about in the APIs and this is > >the most important - If a user had to use createFirewallRule to allow > >ingress traffic and then apply egress rules using a createNetworkACL API > >it makes things inconsistent and unintuitive. > > But you are introducing some other confusion - before publicIPAddress was > required for createFirewallRule and ingress rule was created for a > specific IP; now you are dividing it to 2 paths - ingress per IP and > ingress per network. The DB schema changes have to be made for that, the > constructors for firewallRule have to be changed, etc. > I feel it is important to surface a clean and condensed API over implementation. Don't you agree? In enterprises, it is common to allow inbound traffic from specific locations and block certain outbound services. Example SSH, IRC - outbound 22, 6667 blocked by most enterprises. SysAdmins call this firewall-ing if I'm right. Perhaps we are confusing terminology of ingress/egress with inbound/outbound filtering? > > > >In summary - The scope of this change is limited to VR and SRX firewall > >filtering. For guest networks right now it is a value-add to allow > >filtering ingress /egress rules and simplify the view for the user. > >Implementing ACLs will require a deeper change and rethink of our current > >firewall/acl behaviour. > > > I would still advise to go with networkACLs. The api calls already have > all the parameters you need, all the backend logic is in place. Plus in > the future we are planning to enhance the functionality by adding > ALLOW/DENY permissions and Priority to the network ACLs. > Where is the discussion on this? I must have missed it on the lists. Can you please expand on the ALLOW/DENY permissions and priority of ACL behaviour? IIUC, are you talking about sequentially processsing ACL rules? -- Prasanna.,
