netfilter buglog - Jan 2018 - [Bug 1220] New: Reverse path filtering using "fib" needs better documentation

https://bugzilla.netfilter.org/show_bug.cgi?id=1220

            Bug ID: 1220
           Summary: Reverse path filtering using "fib" needs better
                    documentation
           Product: nftables
           Version: unspecified
          Hardware: All
                OS: All
            Status: NEW
          Severity: minor
          Priority: P5
         Component: nft
          Assignee: pablo at netfilter.org
          Reporter: f30 at f30.me

Reverse path filtering means dropping a packet if connections to its source IP
wouldn't use the same interface the packet arrived on. The nftables wiki
states
[1] that this can be implemented like:

  nft add rule x prerouting fib saddr . iif oif eq 0 drop

Slides by Florian Westphal [2] suggest to use:

  nft add rule ... fib saddr . oif oif = 0 drop

But this fails with "Invalid argument" even when replacing
"=" by "==" or "eq".

`fib saddr . iif oif eq 0` achieves the desired goal (except for bugs like the
one I'm going to report next), but I'm having a hard time figuring out
why:
As far as I understand, `fib saddr . iif` looks up routing information based on
source address and input interface. `oif` then selects the output interface
from the looked up information.
Most other examples compare that result with an interface name, which is pretty
straight-forward. But I can't tell why and when `oif` would return 0 and why
this can be used for reverse path filtering.

I therefore suggest to add better documentation covering that aspect.

[1] https://wiki.nftables.org/wiki-nftables/index.php/Routing_information#fib
[2] http://www.strlen.de/talks/netdev12_nft_fib.pdf

-- 
You are receiving this mail because:
You are watching all bug changes.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.netfilter.org/pipermail/netfilter-buglog/attachments/20180130/cfbe1cbf/attachment.html>

https://bugzilla.netfilter.org/show_bug.cgi?id=1220

Pablo Neira Ayuso <pablo at netfilter.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |fw at strlen.de

-- 
You are receiving this mail because:
You are watching all bug changes.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.netfilter.org/pipermail/netfilter-buglog/attachments/20180202/a098f5f4/attachment-0001.html>

https://bugzilla.netfilter.org/show_bug.cgi?id=1220

--- Comment #1 from Florian Westphal <fw at strlen.de> ---
(In reply to Felix Dreissig from comment #0)
> Reverse path filtering means dropping a packet if connections to its source
> IP wouldn't use the same interface the packet arrived on. The nftables
wiki
> states [1] that this can be implemented like:
> 
>   nft add rule x prerouting fib saddr . iif oif eq 0 drop
> 
> Slides by Florian Westphal [2] suggest to use:
> 
>   nft add rule ... fib saddr . oif oif = 0 drop
> 
> But this fails with "Invalid argument" even when replacing
"=" by "==" or
> "eq".
Yes, the slides were created while FIB was work-in-progress.
> `fib saddr . iif oif eq 0` achieves the desired goal (except for bugs like
> the one I'm going to report next), but I'm having a hard time
figuring out
> why:
> As far as I understand, `fib saddr . iif` looks up routing information
based
> on source address and input interface. `oif` then selects the output
> interface from the looked up information.
> Most other examples compare that result with an interface name, which is
> pretty straight-forward. But I can't tell why and when `oif` would
return 0
> and why this can be used for reverse path filtering.
Indeed, this is not documented properly.

oif is 0 when no route was found.

When 'saddr . iif' is used, the kernel is supposed to also
check that oif == iif; i.e. it return iif (oif and iif are the same and
thereforce reply would leave via iif/oif), or 0 (no route or route via
different interface).

Does that make sense to you?
I'll try to add something to nft man page to cover this.

-- 
You are receiving this mail because:
You are watching all bug changes.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.netfilter.org/pipermail/netfilter-buglog/attachments/20180205/4a318cec/attachment.html>

https://bugzilla.netfilter.org/show_bug.cgi?id=1220

Felix Dreissig <f30 at f30.me> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |f30 at f30.me

--- Comment #2 from Felix Dreissig <f30 at f30.me> ---
(In reply to Florian Westphal from comment #1)
> When 'saddr . iif' is used, the kernel is supposed to also
> check that oif == iif; i.e. it return iif (oif and iif are the same and
> thereforce reply would leave via iif/oif), or 0 (no route or route via
> different interface).
> 
> Does that make sense to you?
Kind of – it is the behavior I already assumed and it enables my use case, but
I wouldn't call it intuitive.

Does this additional check only apply for `saddr . iif`, or also for other keys
like `saddr` alone?
> I'll try to add something to nft man page to cover this.
That sounds good.

Adding a note to the wiki page [1] would be nice as well. I'd also do that
myself, but it seems like new accounts cannot be created.

[1] https://wiki.nftables.org/wiki-nftables/index.php/Routing_information

-- 
You are receiving this mail because:
You are watching all bug changes.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.netfilter.org/pipermail/netfilter-buglog/attachments/20180207/3b1784a3/attachment.html>

https://bugzilla.netfilter.org/show_bug.cgi?id=1220

Florian Westphal <fw at strlen.de> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Assignee|pablo at netfilter.org         |fw at strlen.de

-- 
You are receiving this mail because:
You are watching all bug changes.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.netfilter.org/pipermail/netfilter-buglog/attachments/20190712/e52a6b5a/attachment.html>

https://bugzilla.netfilter.org/show_bug.cgi?id=1220

Florian Westphal <fw at strlen.de> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|---                         |FIXED
             Status|NEW                         |RESOLVED

-- 
You are receiving this mail because:
You are watching all bug changes.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.netfilter.org/pipermail/netfilter-buglog/attachments/20190722/3a3127e0/attachment-0001.html>