netdev - Re: [patch net-next RFC] netfilter: ip6_tables: use reasm skb for matching

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 for Android: free password hash cracker in your pocket

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

Message-ID: <20131104152226.GA5103@minipsycho.orion>
Date:	Mon, 4 Nov 2013 16:22:26 +0100
From:	Jiri Pirko <jiri@...nulli.us>
To:	Florian Westphal <fw@...len.de>
Cc:	netdev@...r.kernel.org, davem@...emloft.net, pablo@...filter.org,
	netfilter-devel@...r.kernel.org, yoshfuji@...ux-ipv6.org,
	kadlec@...ckhole.kfki.hu, kaber@...sh.net, mleitner@...hat.com
Subject: Re: [patch net-next RFC] netfilter: ip6_tables: use reasm skb for
 matching

Wed, Oct 30, 2013 at 03:44:00PM CET, fw@...len.de wrote:
>Jiri Pirko <jiri@...nulli.us> wrote:
>> >This is a bit backwards, I think.
>> >- We gather frags
>> >- Then we invoke ip6t_do_table for each individual fragment
>> >
>> >So basically your patch is equivalent to
>> >for_each_frag( )
>> >  ip6t_do_table(reassembled_skb)
>> >
>> >Which makes no sense to me - why traverse the ruleset n times with the same
>> >packet?
>> 
>> Because each fragment need to be pushed through separately.
>
>Why?  AFAIU we only need to ensure that (in forwarding case) we
>send out the original fragments instead of the reassembled packet.

I don't knot why, that's the way it is done now. From the top of my head
I can't think of any scenario why it would hurt to push the reassebled
packet instead (and of course send out original fragments at the end of
the way for forwarding)

>
>> What different approach would you suggest?
>
>I am sure that current behaviour is intentional, so I'd first like to
>understand WHY this was implemented this way.
>
>Also, this would change very long standing behaviour so one might argue that
>this is a no-go anyway.

Can you think aof any sane use case this change could possible break?

>
>What is the exact problem that this is supposed to solve?

Look at the patch description. There's an example. The problem is that
fragments are not correctly matched.


--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html