ip_pipeline firewall customization

ip_pipeline firewall customization

[Shyam Shrivastav]

Hi All

I am using ip_pipeline firewall as base for our project, need
comments/suggestions/corrections regarding following

1) We can not configure firewall  rule to drop packets, as portid is
mandatory in command. I am planning to allow this for our requirement with
following code changes
      a) Allow "port" as optional parameter (pipeline_firewall.c), pass -1
as port id if "port" is not specified to app_pipeline_firewall_add_rule and
change that parameter to int32_t.
      b) Make required changes in pipeline_firewall_msg_req_add_handler if
portid is -1, that is table entry action to be .action =
RTE_PIPELINE_ACTION_DROP.

2) I am registering a f_action_hit function for firewall table to perform
certain translations if action is pass (RTE_PIPELINE_ACTION_PORT).
Configured a rule like following

pipeline>p 1 firewall add priority 1 ipv4 0.0.0.0 0 0.0.0.0 0 0 65535 0
65535 0 0 port 0

which should be hit only by ipv4 packets. However even ARP packets are hit
by this ACL and my routine is called. If I configure a specific src or dst
ip then everything works fine and arp packets are not hit , for example
following rule hits only ipv4 icmp packets

pipeline>  p 1 firewall add priority 1 ipv4 0.0.0.0 0 45.35.70.12 32 0
65535 0 65535 1 0xf port 0

Is this a bug or am I missing something ?


Thanks
Shyam

Re: ip_pipeline firewall customization

[Dumitrescu, Cristian]

Hi Shyam,

> -----Original Message-----
> From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Shyam Shrivastav
> Sent: Wednesday, March 8, 2017 3:55 PM
> To: dev@dpdk.org
> Cc: Shyam Shrivastav <shrivastav.shyam@gmail.com>
> Subject: [dpdk-dev] ip_pipeline firewall customization
> 
> Hi All
> 
> I am using ip_pipeline firewall as base for our project, need
> comments/suggestions/corrections regarding following
> 
> 1) We can not configure firewall  rule to drop packets, as portid is
> mandatory in command. I am planning to allow this for our requirement with
> following code changes
>       a) Allow "port" as optional parameter (pipeline_firewall.c), pass -1
> as port id if "port" is not specified to app_pipeline_firewall_add_rule and
> change that parameter to int32_t.
>       b) Make required changes in pipeline_firewall_msg_req_add_handler if
> portid is -1, that is table entry action to be .action =
> RTE_PIPELINE_ACTION_DROP.
> 

You don't really need to do this for implementing a drop action. You can simply create a SINK output port (which basically drops all the packets directed to it) and set this as the output port for all rules that drop packet.

See ip_pipeline/config/firewall.cfg as example.

> 2) I am registering a f_action_hit function for firewall table to perform
> certain translations if action is pass (RTE_PIPELINE_ACTION_PORT).

What type of actions are you performing? If generic enough, it would be interesting to add them to this pipeline, so I encourage you to contribute with ideas and code patches.

> Configured a rule like following
> 
> pipeline>p 1 firewall add priority 1 ipv4 0.0.0.0 0 0.0.0.0 0 0 65535 0
> 65535 0 0 port 0
> 
> which should be hit only by ipv4 packets. However even ARP packets are hit
> by this ACL and my routine is called. If I configure a specific src or dst
> ip then everything works fine and arp packets are not hit , for example
> following rule hits only ipv4 icmp packets
> 
> pipeline>  p 1 firewall add priority 1 ipv4 0.0.0.0 0 45.35.70.12 32 0
> 65535 0 65535 1 0xf port 0
> 
> Is this a bug or am I missing something ?
> 

You can make sure no ARP packets are received by the firewall pipeline by simply filtering all the ARP packets to a separate RXQ of the NIC port, which can be further handled by a separate function.

See ip_pipeline/config/network_layers.cfg as example:
[LINK0]
arp_q = 4

> 
> Thanks
> Shyam

Regards,
Cristian

Re: ip_pipeline firewall customization

[Shyam Shrivastav]

Hi Cristian

Please see my comments inline (in blue)

>       b) Make required changes in pipeline_firewall_msg_req_add_handler if
> > portid is -1, that is table entry action to be .action =
> > RTE_PIPELINE_ACTION_DROP.
> >
>
> You don't really need to do this for implementing a drop action. You can
> simply create a SINK output port (which basically drops all the packets
> directed to it) and set this as the output port for all rules that drop
> packet.
>
> See ip_pipeline/config/firewall.cfg as example.
>

Yes dropping of packets can be achieved by creating a sink port. However we
need further processing to be done for a packet hitting a pass rule, and
best way for this processing is f_action_hit table handler.  In this
routine we can distinguish between drop/pass actions as
rte_pipeline_table_entry is passed to it, which also contains  portid but
no generic way to  distinguish between normal or sink port.
I think it would be value addition to allow this action in firewall
pipeline, please let me know your thoughts. As for our project looks like
we have to include this.


>
> > 2) I am registering a f_action_hit function for firewall table to perform
> > certain translations if action is pass (RTE_PIPELINE_ACTION_PORT).
>
> What type of actions are you performing? If generic enough, it would be
> interesting to add them to this pipeline, so I encourage you to contribute
> with ideas and code patches.
>
>
Probably it's not generic, involves vlan translation and mac swapping to
inject the "passed" packets back to the router to travel to next hop.
Router injects traffic for filtering to directly connected firewall port
with vlan tag say A , firewall in turn injects pass traffic with different
vlan tag say B back to the router which then does next hop processing.


> >
> > Is this a bug or am I missing something ?
> >
>
> You can make sure no ARP packets are received by the firewall pipeline by
> simply filtering all the ARP packets to a separate RXQ of the NIC port,
> which can be further handled by a separate function.
>
> See ip_pipeline/config/network_layers.cfg as example:
> [LINK0]
> arp_q = 4
>

There are two things here

1) ARP packets should not hit the ipv4 acl which looks like happening, have
not worked on "why part" for now , need to look at the
rte_table_acl_lookup->rte_acl_classify.

2) Yes we can filter ARP packets to a separate queue and to separate lcore
at link level, but need to decide whether its worth it. We are planning to
use ipv4 RSS (with 8 queues, lcores and processors) wherein all arp packets
would get filtered to queue 0 by default and then dropped by ACL.


Thanks and regards
Shyam

Re: ip_pipeline firewall customization

[Shyam Shrivastav]

My mistake, arp packets are hit by

pipeline>p 1 firewall add priority 1 ipv4 0.0.0.0 0 0.0.0.0 0 0 65535 0
65535 0 0 port 0

ACL as anything and rightly so gets matched for above fields. Only way is
to somehow avoid ARP packets being input to table itself, and yes one way
is to direct them to a separate queue .Another is  explicitly filtering
them before or after  firewall table look up, firewall table is supposed to
be only for ipv4/ipv6 packets ....have to work/think more on this

On Thu, Mar 9, 2017 at 5:13 PM, Shyam Shrivastav <shrivastav.shyam@gmail.com
> wrote:

> Hi Cristian
>
> Please see my comments inline (in blue)
>
> >       b) Make required changes in pipeline_firewall_msg_req_add_handler
>> if
>> > portid is -1, that is table entry action to be .action =
>> > RTE_PIPELINE_ACTION_DROP.
>> >
>>
>> You don't really need to do this for implementing a drop action. You can
>> simply create a SINK output port (which basically drops all the packets
>> directed to it) and set this as the output port for all rules that drop
>> packet.
>>
>> See ip_pipeline/config/firewall.cfg as example.
>>
>
> Yes dropping of packets can be achieved by creating a sink port. However
> we need further processing to be done for a packet hitting a pass rule, and
> best way for this processing is f_action_hit table handler.  In this
> routine we can distinguish between drop/pass actions as
> rte_pipeline_table_entry is passed to it, which also contains  portid but
> no generic way to  distinguish between normal or sink port.
> I think it would be value addition to allow this action in firewall
> pipeline, please let me know your thoughts. As for our project looks like
> we have to include this.
>
>
>>
>> > 2) I am registering a f_action_hit function for firewall table to
>> perform
>> > certain translations if action is pass (RTE_PIPELINE_ACTION_PORT).
>>
>> What type of actions are you performing? If generic enough, it would be
>> interesting to add them to this pipeline, so I encourage you to contribute
>> with ideas and code patches.
>>
>>
> Probably it's not generic, involves vlan translation and mac swapping to
> inject the "passed" packets back to the router to travel to next hop.
> Router injects traffic for filtering to directly connected firewall port
> with vlan tag say A , firewall in turn injects pass traffic with different
> vlan tag say B back to the router which then does next hop processing.
>
>
>> >
>> > Is this a bug or am I missing something ?
>> >
>>
>> You can make sure no ARP packets are received by the firewall pipeline by
>> simply filtering all the ARP packets to a separate RXQ of the NIC port,
>> which can be further handled by a separate function.
>>
>> See ip_pipeline/config/network_layers.cfg as example:
>> [LINK0]
>> arp_q = 4
>>
>
> There are two things here
>
> 1) ARP packets should not hit the ipv4 acl which looks like happening,
> have not worked on "why part" for now , need to look at the
> rte_table_acl_lookup->rte_acl_classify.
>
> 2) Yes we can filter ARP packets to a separate queue and to separate lcore
> at link level, but need to decide whether its worth it. We are planning to
> use ipv4 RSS (with 8 queues, lcores and processors) wherein all arp packets
> would get filtered to queue 0 by default and then dropped by ACL.
>
>
> Thanks and regards
> Shyam
>
>
>

Re: ip_pipeline firewall customization

[Singh, Jasvinder]

Hi Shayam,

From: Shyam Shrivastav [mailto:shrivastav.shyam@gmail.com]
Sent: Thursday, March 9, 2017 1:50 PM
To: Dumitrescu, Cristian <cristian.dumitrescu@intel.com>
Cc: dev@dpdk.org; Singh, Jasvinder <jasvinder.singh@intel.com>
Subject: Re: [dpdk-dev] ip_pipeline firewall customization

My mistake, arp packets are hit by

pipeline>p 1 firewall add priority 1 ipv4 0.0.0.0 0 0.0.0.0 0 0 65535 0 65535 0 0 port 0
ACL as anything and rightly so gets matched for above fields. Only way is to somehow avoid ARP packets being input to table itself, and yes one way is to direct them to a separate queue .Another is  explicitly filtering them before or after  firewall table look up, firewall table is supposed to be only for ipv4/ipv6 packets ....have to work/think more on this

[Jasvinder] -  You need to set the right proto field and accordingly the mask in the above rule. You can keep src/dst ip addresses intact. Proto field defines the protocol used in the data portion of the IP datagram and can be find here<https://en.wikipedia.org/wiki/List_of_IP_protocol_numbers>. For e.g. in case you packet is TCP packet then firewall rule should be as below and you will see arp packets filtered out.

p 1 firewall add priority 1 ipv4 0.0.0.0 0 0.0.0.0 0 0 65535 0 65535 6 0x6 port 0


On Thu, Mar 9, 2017 at 5:13 PM, Shyam Shrivastav <shrivastav.shyam@gmail.com<mailto:shrivastav.shyam@gmail.com>> wrote:
Hi Cristian

Please see my comments inline (in blue)

>       b) Make required changes in pipeline_firewall_msg_req_add_handler if
> portid is -1, that is table entry action to be .action =
> RTE_PIPELINE_ACTION_DROP.
>

You don't really need to do this for implementing a drop action. You can simply create a SINK output port (which basically drops all the packets directed to it) and set this as the output port for all rules that drop packet.

See ip_pipeline/config/firewall.cf<http://firewall.cf>g as example.

Yes dropping of packets can be achieved by creating a sink port. However we need further processing to be done for a packet hitting a pass rule, and best way for this processing is f_action_hit table handler.  In this routine we can distinguish between drop/pass actions as rte_pipeline_table_entry is passed to it, which also contains  portid but no generic way to  distinguish between normal or sink port.
I think it would be value addition to allow this action in firewall pipeline, please let me know your thoughts. As for our project looks like we have to include this.

[Jasvinder] -  If I understand your context correctly, you want to distinguish Sink port from other normal out ports in the action handler. Can do that by keeping sink port last among the pipeline output  ports and then in action handler you can compare the port id (highest value)  to see whether the port id is sink port or not.

> 2) I am registering a f_action_hit function for firewall table to perform
> certain translations if action is pass (RTE_PIPELINE_ACTION_PORT).

What type of actions are you performing? If generic enough, it would be interesting to add them to this pipeline, so I encourage you to contribute with ideas and code patches.

Probably it's not generic, involves vlan translation and mac swapping to inject the "passed" packets back to the router to travel to next hop. Router injects traffic for filtering to directly connected firewall port with vlan tag say A , firewall in turn injects pass traffic with different vlan tag say B back to the router which then does next hop processing.

>
> Is this a bug or am I missing something ?
>

You can make sure no ARP packets are received by the firewall pipeline by simply filtering all the ARP packets to a separate RXQ of the NIC port, which can be further handled by a separate function.

See ip_pipeline/config/network_layers.cfg as example:
[LINK0]
arp_q = 4

There are two things here

1) ARP packets should not hit the ipv4 acl which looks like happening, have not worked on "why part" for now , need to look at the rte_table_acl_lookup->rte_acl_classify.

2) Yes we can filter ARP packets to a separate queue and to separate lcore at link level, but need to decide whether its worth it. We are planning to use ipv4 RSS (with 8 queues, lcores and processors) wherein all arp packets would get filtered to queue 0 by default and then dropped by ACL.

Thanks and regards
Shyam

Re: ip_pipeline firewall customization

[Shyam Shrivastav]

Hi Singh

Please find my comments inline


>
> [Jasvinder] -  You need to set the right proto field and accordingly the
> mask in the above rule. You can keep src/dst ip addresses intact. Proto
> field defines the protocol used in the data portion of the IP datagram and
> can be find here
> <https://en.wikipedia.org/wiki/List_of_IP_protocol_numbers>. For e.g. in
> case you packet is TCP packet then firewall rule should be as below and you
> will see arp packets filtered out.
>
>
>
> p 1 firewall add priority 1 ipv4 0.0.0.0 0 0.0.0.0 0 0 65535 0 65535 6 0x6
> port 0
>
>

[Shyam]    Yes it works already saw that, simple reason that it would be
rare for an arp packet to have exactly same value at that offset (9 which
contains mac address). Still in my view ARP packets must be filtered out
and must never hit firewall/ACL table.




>
>
>
>
> Yes dropping of packets can be achieved by creating a sink port. However
> we need further processing to be done for a packet hitting a pass rule, and
> best way for this processing is f_action_hit table handler.  In this
> routine we can distinguish between drop/pass actions as
> rte_pipeline_table_entry is passed to it, which also contains  portid but
> no generic way to  distinguish between normal or sink port.
> I think it would be value addition to allow this action in firewall
> pipeline, please let me know your thoughts. As for our project looks like
> we have to include this.
>
>
>
> [Jasvinder] -  If I understand your context correctly, you want to
> distinguish Sink port from other normal out ports in the action handler.
> Can do that by keeping sink port last among the pipeline output  ports and
> then in action handler you can compare the port id (highest value)  to see
> whether the port id is sink port or not.
>
>
>
[Shyam]  That doesn't seem to be generic at all. Requirement is to be able
to configure and distinguish between pass and drop rules, so that required
translations can be done for pass rules.  Support for drop action exist in
the underlying table/acl code , we just need to change the firewall part.
We should not do this based on port number in my view ....


Thanks and rgds
Shyam