netdev - Re: [PATCH net] net/sched: act_mirred: fix fragment the packet after defrag in act

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Thu, 2 Jul 2020 17:36:38 +0800
From:   wenxu <wenxu@...oud.cn>
To:     Cong Wang <xiyou.wangcong@...il.com>
Cc:     Linux Kernel Network Developers <netdev@...r.kernel.org>
Subject: Re: [PATCH net] net/sched: act_mirred: fix fragment the packet after
 defrag in act_ct


On 7/2/2020 1:33 AM, Cong Wang wrote:
> On Wed, Jul 1, 2020 at 1:21 AM wenxu <wenxu@...oud.cn> wrote:
>>
>> On 7/1/2020 2:21 PM, wenxu wrote:
>>> On 7/1/2020 2:12 PM, Cong Wang wrote:
>>>> On Tue, Jun 30, 2020 at 11:03 PM wenxu <wenxu@...oud.cn> wrote:
>>>>> Only forward packet case need do fragment again and there is no need do defrag explicit.
>>>> Same question: why act_mirred? You have to explain why act_mirred
>>>> has the responsibility to do this job.
>>> The fragment behavior only depends on the mtu of the device sent in act_mirred. Only in
>>>
>>> the act_mirred can decides whether do the fragment or not.
>> Hi cong,
>>
>>
>> I still think this should be resolved in the act_mirred.  Maybe it is not matter with a "responsibility"
>>
>> Did you have some other suggestion to solve this problem?
> Like I said, why not introduce a new action to handle fragment/defragment?
>
> With that, you can still pipe it to act_ct and act_mirred to achieve
> the same goal.

Thanks.  Consider about the act_fagment, There are two problem for this.


The frag action will put the ressemble skb to more than one packets. How these packets

go through the following tc filter or chain?


When should use the act_fragament the action,  always before the act_mirred?


rule1 in chain0

eth_type ipv4 dst_ip 1.1.1.1 ip_flags frag/firstfrag  

action order 1: ct zone 1 nat pipe

action order 2: gact action goto chain 4


rule2 in chain0

eth_type ipv4 dst_ip 1.1.1.1 ip_flags frag/nofirstfrag  

action order 1: ct zone 1 nat pipe

action order 2: gact action goto chain 4


fragment 1 and 2 do the defag and conntrack nat jump to rule3 in chain4


dst_mac fa:ff:ff:ff:ff:ff
src_mac 52:54:00:00:12:34
  eth_type ipv4
  ip_flags nofrag
  ct_state +trk+est
  ct_zone 1

action order 1: mirred (Egress Redirect to device net2) stolen


There is no definitely reason for user to set the act_fragment action. Or

there is a key  ip_frags ressembly?