> On 9. Nov 2017, at 12:40, Neels Hofmeyr <[email protected]> wrote:
> 
> My questions are:
> 
> - Is it implemented this way for performance considerations?

The performance consideration doesn't have anything to do with the order of
matches. Not to use longest matching rule might be considered a performance
consideration (both at runtime and implementation).

Because there is no longest match a rule set (think of it in terms of first
and then second rule) can not work.

        imsi-deny "all"
        imsi-allow "neels"


In hindsight what would have been better is to define a policy "deny/allow"
per access-list and then people can build opt-in or opt-out

        (allow every one but neels):

        access-list foo default allow
        access-list foo imsi-deny "neels"

        (deny everone one but neels):
        access-list foo default deny
        access-list foo imsi-allow "neels"

Usecases where something like this. In this group only XYZ country IMSIs are
allowed. But if you operate this as a testcell allow your own IMSI as well. Or
for test cells.. No local IMSIs but allow my local IMSI.


> - Are we not going to change this, even assuming that we regard changes being
>  useful, because we don't want to break with previous configs?

I think any existing user of osmo-bsc already will already have difficulties
to upgrade, changing the access lists might not make a big difference?



> - When looking in auth_imsi(), the access list names are:
>   auth_imsi() name | comments | osmo-bsc passes
>            bsc_lst   "local"    vty 'msc' level access rules
>           nat_lst   "global"   vty 'bsc' level access rules
>  Needless to say that "local", "global", "nat", "bsc" and "msc" are quite
>  hard to follow.

Sorry about that. I haven't looked at the code but it started in the NAT and
then was generalized to be used in the BSC as well.

>  From the osmo-bsc filter code's perspective, there may be multiple MSCs
>  configured, and per-msc config could be seen as more specific ("local") than
>  bsc level, which applies to all MSCs ("global")... Was that the intention or
>  is the local/global actually swapped by accident?
>  (I notice that this feature seems to be intended for osmo-bsc-nat, and
>  there's also a concept of a super-global blacklist that is always NULL in
>  osmo-bsc.)

super-global? Hehe. In terms of terminology and system. Upstream for the
BSC is a MSC (or bsc-nat that emulates the A-link of a MSC) and the upstream
for the bsc-nat is a real MSC (or another nat). Local depends where you are
so just saying "BSC" might not be that clear either?


holger

Reply via email to