Re: [PATCH nft] doc: extend description of fib expression

[Pablo Neira Ayuso <pablo@netfilter.org>]

On Fri, Oct 18, 2024 at 02:08:25PM +0200, Florian Westphal wrote:
> Pablo Neira Ayuso <pablo@netfilter.org> wrote:
> > > -|Keyword| Description| Type
> > > +|flag| Description
> > > +|daddr| Perform a normal route lookup: search fib for route to the *destination address* of the packet.
> > > +|saddr| Perform a reverse route lookup: search the fib for route to the *source address* of the packet.
> > > +|mark | consider the packet mark (nfmark) when querying the fib.
> > > +|iif  | fail fib lookup unless route exists and its output interface is identical to the packets input interface
> > 
> > maybe easier to understand?
> > 
> >            if fib lookups provides a route then check its output interface is identical to the packets *input* interface.
> > 
> > > +|oif  | fail fib lookup unless route exists and its output interface is identical to the packets output interface.
> > 
> >            if fib lookups provides a route then check its output interface is identical to the packets *output* interface.
> 
> Its better, updated, thanks.
> 
> > > This flag can only be used with the *type* result.
> > 
> > Are you sure 'oif' can only be used with type? I can see NFTA_FIB_F_OIF is available in nft_fib4_eval()
> > 
> >         if (priv->flags & NFTA_FIB_F_OIF)
> >                 oif = nft_out(pkt);
> >         else if (priv->flags & NFTA_FIB_F_IIF)
> >                 oif = nft_in(pkt);
> >         else
> >                 oif = NULL;
> 
> Seems to be dead code.  nft_fib_init() has:
>         switch (priv->result) {
>         case NFT_FIB_RESULT_OIF:
>                 if (priv->flags & NFTA_FIB_F_OIF)
>                         return -EINVAL;
>                 len = sizeof(int);
>                 break;
>         case NFT_FIB_RESULT_OIFNAME:
>                 if (priv->flags & NFTA_FIB_F_OIF)
>                         return -EINVAL;
>                 len = IFNAMSIZ;
> 
> 
> since _OIF and _OIFNAME was restricted to prerouting, nf hookfn has NULL
> output interface, so there is nothing we could compare against.
> 
> Now its available in forward too so it could be selectively relaxed for
> this, but, what is the use case?
> 
> Do a RPF in forward, then we need to compare vs. incoming interface.

This is for an esoteric scenario: Policy-based routing using input
interface as key. The fib rule for RPF does not work from prerouting
because iif cannot be inferred, there is no way to know if route in
the reverse direction exists until the route lookup for this direction
is done.

commit be8be04e5ddb9842d4ff2c1e4eaeec6ca801c573
Author: Pablo Neira Ayuso <pablo@netfilter.org>
Date:   Thu Mar 31 17:14:47 2022 +0200

    netfilter: nft_fib: reverse path filter for policy-based routing on iif

    If policy-based routing using the iif selector is used, then the fib
    expression fails to look up for the reverse path from the prerouting
    hook because the input interface cannot be inferred. In order to support
    this scenario, extend the fib expression to allow to use after the route
    lookup, from the forward hook.

> But for outgoing interface, we'd do a normal route lookup, but the stack
> already did that for us (as packet is already being forwarded).
>
> So what would be the desired outcome for a 'fib daddr . oif' check?

Hm, this always evaluates true from forward and any later hook.

I missing now, what is the point of . oif in general?