cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Anthony Xu <Xuefei...@citrix.com>
Subject RE: Egress firewall rules for guest network.
Date Mon, 15 Oct 2012 01:08:17 GMT
> 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+firewal
>>>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