RE: Egress firewall rules for guest network.

[Jayapal Reddy Uradi <ja...@citrix.com>]

Updated the Egress firewall rules  FS.

https://cwiki.apache.org/confluence/display/CLOUDSTACK/Egress+firewall+rules+for+guest+network

Thanks,
Jayapal

> -----Original Message-----
> From: Jayapal Reddy Uradi [mailto:jayapalreddy.uradi@citrix.com]
> Sent: Wednesday, October 17, 2012 8:12 PM
> To: cloudstack-dev@incubator.apache.org; Anthony Xu
> Subject: RE: Egress firewall rules for guest network.
> 
> I am updating egress firewall rules FS with the createNetworkACL.
> 
> Thanks,
> Jayapal
> 
> > -----Original Message-----
> > From: Alena Prokharchyk [mailto:Alena.Prokharchyk@citrix.com]
> > Sent: Tuesday, October 16, 2012 10:28 PM
> > To: cloudstack-dev@incubator.apache.org; Anthony Xu
> > Subject: Re: Egress firewall rules for guest network.
> >
> >
> > On 10/16/12 8:34 AM, "Jayapal Reddy Uradi"
> > <ja...@citrix.com>
> > wrote:
> >
> > >
> > >Though CreateNetworkACL  and CreateFirewallRule   APIs  are configuring
> > >the firewall rules,  but there is difference in the purpose for which
> > >it is used.
> > >            CreateNetworkACL  - API  is used for configuring
> > >firewall rules per  Network.
> >
> >
> > Clarification - per guest network
> >
> > >            CreateFirewallRule  - API is  used for  configuring
> > >firewall rules per  public IP.
> >
> >
> > Jayapal, if your goal is to control egress traffic on the guest
> > network, you should use NetworkACL rule.
> >
> >
> >
> > >
> > >
> > >Thanks,
> > >Jayapal
> >
> >
> > >
> > >
> > >
> > >
> > >
> > >Thanks,
> > >Jayapal
> > >
> > >
> > >
> > >> -----Original Message-----
> > >> From: Anthony Xu
> > >> Sent: Monday, October 15, 2012 6:38 AM
> > >> To: cloudstack-dev@incubator.apache.org
> > >> Cc: Jayapal Reddy Uradi
> > >> Subject: RE: Egress firewall rules for guest network.
> > >>
> > >> > 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.
> > >>
> > >>
> > >> 1. both firewall rule and network ACL rule are stateful. Stateful
> > >>means rule  only check new request , stateless means rule check both
> > >>request and  response.
> > >> 2. firewall rule is against public IP, ACL is against guest
> > >>network, it doesn't  care which public IP it goes through
> > >>
> > >>
> > >> -----Original Message-----
> > >> From: Alena Prokharchyk [mailto:Alena.Prokharchyk@citrix.com]
> > >> Sent: Wednesday, October 10, 2012 9:44 AM
> > >> To: cloudstack-dev@incubator.apache.org
> > >> Cc: Jayapal Reddy Uradi
> > >> Subject: Re: Egress firewall rules for guest network.
> > >>
> > >> Hi Jayapal,
> > >>
> > >> See my comments below.
> > >>
> > >> -Alena.
> > >>
> > >> On 10/10/12 1:50 AM, "Jayapal Reddy Uradi"
> > >> <ja...@citrix.com>
> > >> wrote:
> > >>
> > >> >Hi Alena,
> > >> >
> > >> >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.
> > >>
> > >>
> > >> >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.
> > >>
> > >>
> > >> >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.
> > >>
> > >> >
> > >> >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.
> > >>
> > >> >
> > >> >Thanks,
> > >> >Jayapal
> > >> >
> > >> >-----Original Message-----
> > >> >From: Alena Prokharchyk [mailto:Alena.Prokharchyk@citrix.com]
> > >> >Sent: Tuesday, October 09, 2012 10:43 PM
> > >> >To: cloudstack-dev@incubator.apache.org
> > >> >Subject: Re: Egress firewall rules for guest network.
> > >> >
> > >> >On 10/9/12 8:10 AM, "David Nalley" <da...@gnsa.us> wrote:
> > >> >
> > >> >>On Tue, Oct 9, 2012 at 5:14 AM, Jayapal Reddy Uradi
> > >> >><ja...@citrix.com> wrote:
> > >> >>> The egress firewall rules feature  will configure the egress
> > >> >>>rules for guest network on VR/External firewall to ALLOW
> > >> >>>
> > >> >>> specified traffic to outside and BLOCK the remaining traffic.
> > >> >>>
> > >> >>>
> > >> >>>
> > >> >>> By default  all the traffic is ALLOWED to public network. When
> > >> >>>you specify a egress rule only that rule specific traffic is allowed.
> > >> >>>
> > >> >>>
> > >> >>>
> > >> >>> I have created a functional spec here:
> > >>
> > >>>https://cwiki.apache.org/confluence/display/CLOUDSTACK/Egress+fire
> > >> >>>w
> > >> al
> > >> >>>l
> > >> >>>+ru
> > >> >>>les+for+guest+network
> > >> >>>
> > >> >>>
> > >> >>>
> > >> >>> Please review and provide your comments.
> > >> >>>
> > >> >>> Thanks,
> > >> >>> Jayapal
> > >> >>
> > >> >>
> > >> >>So I noticed you are modifying createFirewallRule in a way which
> > >> >>would break backwards compatibility, or at least make it more
> difficult.
> > >> >>
> > >> >>I'd suggest that trafficType be optional and default to to
> > >> >>ingress
> > >> >>- which means existing calls being issued today should continue
> > >> >>to work as they do now, and folks wishing to take advantage of
> > >> >>egress filtering can pass trafficType=egress for any calls. Is
> > >> >>there any downside to doing it that way that I am missing?
> > >> >>
> > >> >>--David
> > >> >>
> > >> >
> > >> >
> > >> >Agree with David. This is a #1 API modification rule - never ever
> > >> >introduce the required parameter to existing endUser API. Always
> > >> >make it optional, and default it to some value if not specified
> > >> >but required by the backend code.
> > >> >
> > >> >Jayapal, my other question is - why don't you use createNetworkACL
> > >> >instead of createFirewallRule api? createFirewallRule api doesn't
> > >> >quite fit here as it requires publicIpAddress to be passed in. The
> > >> >firewall rule is always created per IP basis, not per network.
> > >> >While in netowrkACL all you need to pass in - networkId and
> > >> >source/dest CIDR (based on the traffic side). And accept id of the
> > >> >public/guest network
> > >>as the
> > >> networkId.
> > >> >
> > >> >I don't like the idea of splitting the logic for
> > >> >createFirewallRule to
> > >> >a) create a rule for the entire network b) create a rule for a
> > >> >particular publicIpAddress. So I advocate to use createNetworkACL
> > >> >as it already has all the parameters you need + the backend
> > >> >implementation is already in (for VPC case only by now, but should
> > >> >be pretty easy to adopt by the regular virtual router).
> > >> >
> > >> >
> > >> >
> > >> >
> > >> >-Alena.
> > >> >
> > >> >
> > >> >
> > >>
> > >
> > >
> >