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.

Reply via email to