incubator-cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jayapal Reddy Uradi <jayapalreddy.ur...@citrix.com>
Subject RE: Egress firewall rules for guest network.
Date Wed, 17 Oct 2012 14:41:41 GMT
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"
> <jayapalreddy.uradi@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"
> >> <jayapalreddy.uradi@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" <david@gnsa.us> wrote:
> >> >
> >> >>On Tue, Oct 9, 2012 at 5:14 AM, Jayapal Reddy Uradi
> >> >><jayapalreddy.uradi@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.
> >> >
> >> >
> >> >
> >>
> >
> >
> 


Mime
View raw message