On Mon, Jan 25, 2021 at 02:30:46PM +0100, Alexandr Nedvedicky wrote:
> Hello,
>
> </snip>
...
> >
> > i dont understand the kif lifetimes though. can we just point a
> > pdesc at an arbitrary kif or do we need ot reference count?
> >
>
> as long as we don't release NET_LOCK() (or PF_LOCK() in near future),
> the reference to kif should remain valid.
>
> kif is very own PF's abstraction of network interfaces. there are
> two ways how one can create a kif:
>
> there is either rule loaded, which refers to interface, which
> is not plumbed yet.
>
> the new interface gets plumbed and PF must have a kif for it.
>
> the reference count currently used makes sure we destroy kif when
> either interface is gone or when the rule, which refers kif is
> gone.
>
> hope I remember details above right.
ok. sounds simple enough...
> > > I think this might be way to go.
> > >
> > > My only concern now is that such change is subtle. I mean the
> > >
> > > pass out ... route-to <hops>
> > >
> > > will change behavior in sense that current code will dispatch
> > > packet to new interface and run pf_test() again. Once your diff
> > > will be in the same rule will be accepted, but will bring entirely
> > > different behaviour: just dispatch packet to new interface.
> >
> > yeah.
> >
> > the counter example is that i was extremely surprised when i
> > discovered that pf_test gets run again when the outgoing interface
> > is changed with a route-to rule.
>
> surprised because you've forgot about current model? which is:
> run pf_test() whenever packet crosses the interface?
forgot isn't the right word. i was in the room when henning and mcbride
reworked pf and came up with the stack and wire side key terminology and
semantics, and i've spent a lot of time looking at the ip input and
output code where pf_test is called close to the stack. it just wasn't
obvious to me that pf filtered over an interface rather than filtered
in and out of the stack. apart from route-to in pf, i'm not sure it is a
meaningful difference either.
> > there's subtlety either way, we're just figuring out which one we're
> > going for.
>
> yes exactly. there are trade offs either way.
>
> </snip>
>
> > > I think this is acceptable. If this will cause a friction we can
> > > always
> > > adjust the code in follow up commit to allow state-less
> > > route-to/reply-to
> > > with no support from pfsync(4).
> >
> > if we're going to support route-to on match rules i think this will be
> > easy to implement.
> >
>
> I think there must be some broader consent on model change
> from current which is run pf_test() for every NIC crossing
> to new way, which is run pf_test() at most two times.
agreed.
> > > > > > lastly, the "argument" or address specified with route-to (and
> > > > > > reply-to and dup-to) is a destination address, not a next-hop. this
> > > > > > has been discussed on the lists a couple of times before, so i won't
> > > > > > go over it again, except to reiterate that it allows pf to force
> > > > > > "sticky" path selection while opening up the possibility for ecmp
> > > > > > and failover for where that path traverses.
> > > > >
> > > > > I keep forgetting about it as I still stick to current
> > > > > interpretation.
> > > > >
> > > > >
> > > > > I've seen changes to pfctl. Diff below still allows rule:
> > > > >
> > > > > pass in on net0 from 192.168.1.0/24 to any route-to
> > > > > 10.10.10.10@em0
> > > >
> > > > Is there use case for the @interface syntax apart from the current
> > > > route-to rules? If not, we can just delete it.
> > >
> > > perhaps I'm still not quite on the same page as you then. I also
> > > had no time to entirely test you diff. The way I understand your
> > > effort is to change route-to behavior such it will be using
> > > a destination instead of next-hop@interface. Or are you planning
> > > to keep current form ('route-to next-hop@interface') working?
> >
> > if we ignore route-to, what's the use case for the interface part of
> > address@interface? it doesnt seem to be accepted as part of an address
> > in other parts of the grammar:
> >
> > dlg@kbuild ~$ echo pass in from 192.168.0.0@vmx0 | sudo pfctl -nf -
> > stdin:1: @if syntax not permitted in from or to
> > stdin:1: skipping rule due to errors
> > stdin:1: rule expands to no valid combination
> > dlg@kbuild ~$ echo pass from 192.168.0.0@vmx0 | sudo pfctl -nf -
> > stdin:1: @if syntax not permitted in from or to
> > stdin:1: skipping rule due to errors
> > stdin:1: rule expands to no valid combination
> > dlg@kbuild ~$ echo pass nat-to 192.168.0.0@vmx0 | sudo pfctl -nf -
> > stdin:1: @if not permitted
> > stdin:1: nat-to and rdr-to require a direction
> > stdin:1: skipping rule due to errors
> > stdin:1: rule expands to no valid combination
> > dlg@kbuild ~$ echo pass nat-to 192.168.0.0@vmx0 | sudo pfctl -nf -
> >
> > if route-to isn't going to use it, can we cut the @interface part out of
> > fthe address parser?
> >
>
> that's also my understanding. the form 192.168.0.0@net0 is currently
> used by route-to et.al. only. So we can eventually let it go.
goodo.
> however there is a strong objection from Sven, which wants it to keep
> it around.
the way i read his email is that he wants to keep "pass in reply-to"
like i do.
>
> </snip>
> > > unless we don't want to support yet another way of doing block/block
> > > return
> > > we should fail with error, I think.
> >
> > ok. i'll update my diff to have pf_route{,6} check these flags tomorrow.
> >
>
> thanks. I'll continue reading your diff. I'll also keep thinking of
> how to combine all things together to keep Sven and you happy with
> those changes.
i'll need help with "match on em0 route-to $if_em0_peer". or we can do
that later separately?
cheers,
dlg
