* [nftables] economics of reverse path filtering - FIB expression vs. kernel parameter
@ 2020-02-09 12:51 ѽ҉ᶬḳ℠
2020-02-12 11:03 ` ѽ҉ᶬḳ℠
0 siblings, 1 reply; 6+ messages in thread
From: ѽ҉ᶬḳ℠ @ 2020-02-09 12:51 UTC (permalink / raw)
To: netfilter@vger.kernel.org
Presumably NFT rule
* filter prerouting fib saddr . iif oif missing drop
and kernel parameter
net.ipv4.conf.<interface>.rp_filter = 2
achieving the same goal.
Which one comes into effect first, if there is difference assuming that
both are being processed through netfilter?
Is one or the other more economic with regard to CPU cycles and/or
responsiveness?
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [nftables] economics of reverse path filtering - FIB expression vs. kernel parameter
2020-02-09 12:51 [nftables] economics of reverse path filtering - FIB expression vs. kernel parameter ѽ҉ᶬḳ℠
@ 2020-02-12 11:03 ` ѽ҉ᶬḳ℠
2020-02-13 12:35 ` ѽ҉ᶬḳ℠
0 siblings, 1 reply; 6+ messages in thread
From: ѽ҉ᶬḳ℠ @ 2020-02-12 11:03 UTC (permalink / raw)
To: netfilter@vger.kernel.org
On 09/02/2020 12:51, ѽ҉ᶬḳ℠ wrote:
> Presumably NFT rule
>
> * filter prerouting fib saddr . iif oif missing drop
>
> and kernel parameter
>
> net.ipv4.conf.<interface>.rp_filter = 2
>
> achieving the same goal.
>
> Which one comes into effect first, if there is difference assuming
> that both are being processed through netfilter?
> Is one or the other more economic with regard to CPU cycles and/or
> responsiveness?
>
>
Been also wondering about potential conflicts between kernel parameters
vs. firewall rules, which takes precedence?
Another example - here purposely creating a conflict:
* net.ipv6.conf.<interface>.accept_redirects = 0
vs.
* ip6 saddr fe80::/10 ip6 hoplimit 255 daddr FF02::1 icmpv6 type 137 accept;
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [nftables] economics of reverse path filtering - FIB expression vs. kernel parameter
2020-02-12 11:03 ` ѽ҉ᶬḳ℠
@ 2020-02-13 12:35 ` ѽ҉ᶬḳ℠
2020-02-13 12:48 ` Florian Westphal
2020-02-13 12:51 ` Jozsef Kadlecsik
0 siblings, 2 replies; 6+ messages in thread
From: ѽ҉ᶬḳ℠ @ 2020-02-13 12:35 UTC (permalink / raw)
To: netfilter@vger.kernel.org
On 12/02/2020 11:03, ѽ҉ᶬḳ℠ wrote:
> On 09/02/2020 12:51, ѽ҉ᶬḳ℠ wrote:
>> Presumably NFT rule
>>
>> * filter prerouting fib saddr . iif oif missing drop
>>
>> and kernel parameter
>>
>> net.ipv4.conf.<interface>.rp_filter = 2
>>
>> achieving the same goal.
>>
>> Which one comes into effect first, if there is difference assuming
>> that both are being processed through netfilter?
>> Is one or the other more economic with regard to CPU cycles and/or
>> responsiveness?
>>
>>
>
> Been also wondering about potential conflicts between kernel
> parameters vs. firewall rules, which takes precedence?
>
> Another example - here purposely creating a conflict:
>
> * net.ipv6.conf.<interface>.accept_redirects = 0
>
> vs.
>
> * ip6 saddr fe80::/10 ip6 hoplimit 255 daddr FF02::1 icmpv6 type 137
> accept;
>
>
Looked into various publications, including [1], but came up short in
discovering the hierarchy of /proc parameters vs firewall rules/chains, i.e.
* is the kernel treating both the same or considers one or the other
weighing more/higher than the other?
* if treated equally does timing in availability of structures cancels
out the other, e.g. first available sets the rule or the last one
available cancels out the earlier one?
____
[1] https://www.kernel.org/doc/Documentation/filesystems/proc.txt
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [nftables] economics of reverse path filtering - FIB expression vs. kernel parameter
2020-02-13 12:35 ` ѽ҉ᶬḳ℠
@ 2020-02-13 12:48 ` Florian Westphal
2020-02-13 12:51 ` Jozsef Kadlecsik
1 sibling, 0 replies; 6+ messages in thread
From: Florian Westphal @ 2020-02-13 12:48 UTC (permalink / raw)
To: ѽ҉ᶬḳ℠; +Cc: netfilter@vger.kernel.org
ѽ҉ᶬḳ℠ <vtol@gmx.net> wrote:
> On 12/02/2020 11:03, ѽ҉ᶬḳ℠ wrote:
> > On 09/02/2020 12:51, ѽ҉ᶬḳ℠ wrote:
> > > Presumably NFT rule
> > >
> > > * filter prerouting fib saddr . iif oif missing drop
> > >
> > > and kernel parameter
> > >
> > > net.ipv4.conf.<interface>.rp_filter = 2
> > >
> > > achieving the same goal.
> > >
> > > Which one comes into effect first, if there is difference assuming
> > > that both are being processed through netfilter?
prerouting hook comes before routing decision in network stack, so,
if you drop a packet there it will never make it to the routing
decision.
> > Been also wondering about potential conflicts between kernel parameters
> > Another example - here purposely creating a conflict:
> >
> > * net.ipv6.conf.<interface>.accept_redirects = 0
> >
> > vs.
> >
> > * ip6 saddr fe80::/10 ip6 hoplimit 255 daddr FF02::1 icmpv6 type 137
> > accept;
Accepting packet means that processing continues, it
doesn't have any other effect.
So it doesn't matter if you accept redirect packets in nftables or if you
do not have nftables rules at all.
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [nftables] economics of reverse path filtering - FIB expression vs. kernel parameter
2020-02-13 12:35 ` ѽ҉ᶬḳ℠
2020-02-13 12:48 ` Florian Westphal
@ 2020-02-13 12:51 ` Jozsef Kadlecsik
2020-02-13 13:14 ` ѽ҉ᶬḳ℠
1 sibling, 1 reply; 6+ messages in thread
From: Jozsef Kadlecsik @ 2020-02-13 12:51 UTC (permalink / raw)
To: ѽ҉ᶬḳ℠; +Cc: netfilter@vger.kernel.org
[-- Attachment #1: Type: text/plain, Size: 1590 bytes --]
On Thu, 13 Feb 2020, ѽ҉ᶬḳ℠ wrote:
> > Been also wondering about potential conflicts between kernel
> > parameters vs. firewall rules, which takes precedence?
> >
> > Another example - here purposely creating a conflict:
> >
> > * net.ipv6.conf.<interface>.accept_redirects = 0
> >
> > vs.
> >
> > * ip6 saddr fe80::/10 ip6 hoplimit 255 daddr FF02::1 icmpv6 type 137 accept;
>
> Looked into various publications, including [1], but came up short in
> discovering the hierarchy of /proc parameters vs firewall rules/chains,
> i.e.
>
> * is the kernel treating both the same or considers one or the other
> weighing more/higher than the other?
> * if treated equally does timing in availability of structures cancels
> out the other, e.g. first available sets the rule or the last one
> available cancels out the earlier one?
Check out the packet flow in netfilter and the networking stack, eg:
https://upload.wikimedia.org/wikipedia/commons/3/37/Netfilter-packet-flow.svg
A networking subsystem proc/whatever setting have got a chance to tell
what happens with the packet if the netfilter hooks let the packet pass up
to that point. And vice versa: if a subsytem decides to drop the packet
(say routing due to reverse path filtering), then the next netfilter hook
won't/can't process it.
Best regards,
Jozsef
-
E-mail : kadlec@blackhole.kfki.hu, kadlecsik.jozsef@wigner.mta.hu
PGP key : http://www.kfki.hu/~kadlec/pgp_public_key.txt
Address : Wigner Research Centre for Physics
H-1525 Budapest 114, POB. 49, Hungary
^ permalink raw reply [flat|nested] 6+ messages in thread* Re: [nftables] economics of reverse path filtering - FIB expression vs. kernel parameter
2020-02-13 12:51 ` Jozsef Kadlecsik
@ 2020-02-13 13:14 ` ѽ҉ᶬḳ℠
0 siblings, 0 replies; 6+ messages in thread
From: ѽ҉ᶬḳ℠ @ 2020-02-13 13:14 UTC (permalink / raw)
To: netfilter
On 13/02/2020 12:51, Jozsef Kadlecsik wrote:
> On Thu, 13 Feb 2020, ѽ҉ᶬḳ℠ wrote:
>
>>> Been also wondering about potential conflicts between kernel
>>> parameters vs. firewall rules, which takes precedence?
>>>
>>> Another example - here purposely creating a conflict:
>>>
>>> * net.ipv6.conf.<interface>.accept_redirects = 0
>>>
>>> vs.
>>>
>>> * ip6 saddr fe80::/10 ip6 hoplimit 255 daddr FF02::1 icmpv6 type 137 accept;
>> Looked into various publications, including [1], but came up short in
>> discovering the hierarchy of /proc parameters vs firewall rules/chains,
>> i.e.
>>
>> * is the kernel treating both the same or considers one or the other
>> weighing more/higher than the other?
>> * if treated equally does timing in availability of structures cancels
>> out the other, e.g. first available sets the rule or the last one
>> available cancels out the earlier one?
> Check out the packet flow in netfilter and the networking stack, eg:
> https://upload.wikimedia.org/wikipedia/commons/3/37/Netfilter-packet-flow.svg
>
> A networking subsystem proc/whatever setting have got a chance to tell
> what happens with the packet if the netfilter hooks let the packet pass up
> to that point. And vice versa: if a subsytem decides to drop the packet
> (say routing due to reverse path filtering), then the next netfilter hook
> won't/can't process it.
>
> Best regards,
> Jozsef
It was the point of asking the question here, also having perused that
graphic, to understand where the /proc/sys/net/* variables fit in the
packet flow, but now understanding (also as Florian pointed out) that
those variables are processed as part of the routing decision. That make
things clear and helps to design the network protection efficiently.
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2020-02-13 13:14 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2020-02-09 12:51 [nftables] economics of reverse path filtering - FIB expression vs. kernel parameter ѽ҉ᶬḳ℠
2020-02-12 11:03 ` ѽ҉ᶬḳ℠
2020-02-13 12:35 ` ѽ҉ᶬḳ℠
2020-02-13 12:48 ` Florian Westphal
2020-02-13 12:51 ` Jozsef Kadlecsik
2020-02-13 13:14 ` ѽ҉ᶬḳ℠
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.
