incubator-cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alena Prokharchyk <Alena.Prokharc...@citrix.com>
Subject Re: Egress firewall rules for guest network.
Date Tue, 16 Oct 2012 16:57:53 GMT

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+firew
>> 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