You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cloudstack.apache.org by Jayapal Reddy Uradi <ja...@citrix.com> on 2012/10/09 11:14:23 UTC
Egress firewall rules for guest network.
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+firewall+rules+for+guest+network
Please review and provide your comments.
Thanks,
Jayapal
RE: Egress firewall rules for guest network.
Posted by 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.
> > >> >
> > >> >
> > >> >
> > >>
> > >
> > >
> >
RE: Egress firewall rules for guest network.
Posted by Jayapal Reddy Uradi <ja...@citrix.com>.
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.
> >> >
> >> >
> >> >
> >>
> >
> >
>
Re: Egress firewall rules for guest network.
Posted by Alena Prokharchyk <Al...@citrix.com>.
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+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.
>> >
>> >
>> >
>>
>
>
RE: Egress firewall rules for guest network.
Posted by Jayapal Reddy Uradi <ja...@citrix.com>.
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.
CreateFirewallRule - API is used for configuring firewall rules per public IP.
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+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.
> >
> >
> >
>
RE: Egress firewall rules for guest network.
Posted by Anthony Xu <Xu...@citrix.com>.
> 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+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.
>
>
>
Re: Egress firewall rules for guest network.
Posted by Prasanna Santhanam <pr...@citrix.com>.
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.,
Re: Egress firewall rules for guest network.
Posted by Alena Prokharchyk <Al...@citrix.com>.
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+firewall
>>>+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.
>
>
>
RE: Egress firewall rules for guest network.
Posted by Jayapal Reddy Uradi <ja...@citrix.com>.
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.
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. 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.
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.
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.
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+firewall
>>+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.
RE: Egress firewall rules for guest network.
Posted by Jayapal Reddy Uradi <ja...@citrix.com>.
I meant that trafficType is required only while configuring the Egress firewall rule.
It will not affect the backward compatibility.
trafficType (required) - egress (required only for egress rules. For ingress it is not required)
I will also update the spec to avoid the confusion.
Thanks,
Jayapal
-----Original Message-----
From: David Nalley [mailto:david@gnsa.us]
Sent: Wednesday, October 10, 2012 8:41 AM
To: cloudstack-dev@incubator.apache.org
Subject: Re: Egress firewall rules for guest network.
On Tue, Oct 9, 2012 at 11:07 PM, Jayapal Reddy Uradi <ja...@citrix.com> wrote:
> Hi David,
>
> The traffic type is optional and default to ingress. For egress it is required to pass with the 'egress'.
>
> Thanks,
> Jayapal
The fs is very confusing then. In the API parameters and info section there is this line:
trafficType (required) - egress (new argument )
Not sure how to infer optional out of that.
--Davia
Re: Egress firewall rules for guest network.
Posted by David Nalley <da...@gnsa.us>.
On Tue, Oct 9, 2012 at 11:07 PM, Jayapal Reddy Uradi
<ja...@citrix.com> wrote:
> Hi David,
>
> The traffic type is optional and default to ingress. For egress it is required to pass with the 'egress'.
>
> Thanks,
> Jayapal
The fs is very confusing then. In the API parameters and info section
there is this line:
trafficType (required) - egress (new argument )
Not sure how to infer optional out of that.
--David
RE: Egress firewall rules for guest network.
Posted by Jayapal Reddy Uradi <ja...@citrix.com>.
Hi David,
The traffic type is optional and default to ingress. For egress it is required to pass with the 'egress'.
Thanks,
Jayapal
-----Original Message-----
From: David Nalley [mailto:david@gnsa.us]
Sent: Tuesday, October 09, 2012 8:41 PM
To: cloudstack-dev@incubator.apache.org
Subject: Re: Egress firewall rules for guest network.
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+firewall
> +rules+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
Re: Egress firewall rules for guest network.
Posted by Abhinandan Prateek <Ab...@citrix.com>.
On 09/10/12 8:40 PM, "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+firewall+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
+abhi
Yes, that is what we should do.
>
Re: Egress firewall rules for guest network.
Posted by Alena Prokharchyk <Al...@citrix.com>.
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+firewall+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.
Re: Egress firewall rules for guest network.
Posted by David Nalley <da...@gnsa.us>.
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+firewall+rules+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
Re: Egress firewall rules for guest network.
Posted by Abhinandan Prateek <Ab...@citrix.com>.
On 09/10/12 7:24 PM, "Wido den Hollander" <wi...@widodh.nl> wrote:
>On 10/09/2012 11:14 AM, Jayapal Reddy Uradi 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+firewall+ru
>>les+for+guest+network
>>
>>
>>
>> Please review and provide your comments.
>>
>
>Seems great! But why assume that we will block everything when one is
>rule is set?
>
>What if somebody wants to block specific traffic and allow the rest?
>Let's say you don't want to allow IRC traffic, but do allow everything
>else?
>
>Should there be a policy setting: ALLOW/DENY?
>Good if we can make it flexible.
>We have to start from either block all or allow all.
>The issue is that starting from default if we put the next rule of the
>same nature what does that mean ?
> eg. Default allow-all, next rule allow traffic only to a subnet, what
>does that mean ? The interpretation will be that we block everything now
>and allow only this traffic. And then we are in same position.
>I think that what is meant here is that the starting point of allowing
>all or deny all should be configurable, can it create some confusion ?
>-abhi
>
Re: Egress firewall rules for guest network.
Posted by Wido den Hollander <wi...@widodh.nl>.
On 10/09/2012 11:14 AM, Jayapal Reddy Uradi 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+firewall+rules+for+guest+network
>
>
>
> Please review and provide your comments.
>
Seems great! But why assume that we will block everything when one is
rule is set?
What if somebody wants to block specific traffic and allow the rest?
Let's say you don't want to allow IRC traffic, but do allow everything else?
Should there be a policy setting: ALLOW/DENY?
Wido
> Thanks,
> Jayapal
>