Hi, On Tue, 15 Sep 2020 02:31:24 +0200 Klemens Nanni <k...@openbsd.org> wrote: > On Tue, Sep 15, 2020 at 12:30:35AM +0200, Klemens Nanni wrote: >> Actually, that should just work regardless of whether the rounting >> domain exists at ruleset creation time; just like it is the case with >> interface names/groups which may come and go at runtime without >> requiring changes to the ruleset. >> >> Rules on nonexistent interfaces won't match, routing domains (and >> ultimately routing tables) should behave the same, I think. >> >> Here's a diff that does this for routing domains allowing me to always >> use `on rdomain 5' - I've tested it with a few examplatory rulesets and >> behaviour is as expected. >> >> It will need more eye balling and I am not pushing such changes before >> release, but if that is a general direction we agree, your proposed >> `rtable' fix could move along and become just as flexible instead. > More on this: > > # ifconfig lo1 rdomain 1 > # echo pass on rdomain 1 | pfctl -f- > # ifconfig lo1 destroy > # pfctl -sr > > pass on rdomain 1 all flags S/SA > > The ruleset stays valid and continues to work as soon as routing domain > `1' reappears, there is no reason to require existence of it at ruleset > creation; this is safe because routing domains are just normative > numbers, there's no further state when it comes to filtering - either > the id on the packet matches the number in the ruleset or it doesn't. > > Routing tables however are more involved as they can be used to *alter* > a packet's flow in pf.conf(5), so requiring them to be present at > ruleset creation makes sense to guarantee that pf will only ever change > routing table ids to valid ones.
It's not clear for me why non-existing rdomain is accepted but non-existing rtable is rejected. I suppose we can make pf(4) can handle a packet for the non-existing routing table as if the routing table is empty. > Routing domains can be deleted, but that doesn't invalidate rules like > `on rdomain 1', which simply won't match when the given id does not > exist. > > Routing tables however cannot be deleted, they get moved to the default > routing domain whenever their corresponding routing domain disappears; > this is in line with only ever loading valid routing table ids into pf. > > So unless I missed something, that ruleset creation (`pfctl -f ...') > is the only occasion pf actually needs to validate routing table ids: > they are guaranteed to always exist from then on. > > Given this, my diff looks fine as is and should not change `rtable' > behaviour - YASUOKA's diff is also fine as is and actually implements > the validity check I just mentioned, obsoleting my initial feedback.