[bind10-dev] ACL Syntax proposal

[Evan Hunt]

> Or, we could come up with one extra composition modifier, which would
> allow this kind of chaining, which people could use if they really wanted
> (and it would answer yes/no for itself and the chain could be included in
> further logic processing), something like this:
> 
> {
>   "CHAIN": [
>     {"ACCEPT-IF": {"ip": "132.147.67.16"}},
>     {"DENY-IF": {"ip": "132.147.67.0/24"}},
>     {"ACCEPT-IP": {"ip": "132.147.0./16"}},
>     "DENY"
>   ],
>   "TSIG": ["tsig1", "tsig2"]
> }

I like this!  Best of both worlds.  (I might call it "FIRST-MATCH" or
just "FIRST", rather than "CHAIN", to clarify the sequential nature of
the rules, but that's a syntactic quibble.)

> Do you think this would help for the donut cases and such? It would help
> us next year as well, when we'll do the BIND9 compatibility (it still
> shouldn't be a problem to translate the BIND9 ACL to the logic ones
> automatically, but the result wouldn't look nice).

Yes, I agree.

It also might not process as quickly, depending on how we code things.
With a first-match ACL, in principle you try the first rule and if you
get a match you're done, whereas with a boolean expression you might need
to walk a syntax tree to be sure you've covered everything.  We'll need to
be careful about that.

You may want to take a look at the underlying data structure for ACLs
in BIND 9 (though it will hurt your head to do so, and I will need to buy
you a recreational beverage of your choice to apologize for the way I
wrote it).

Basically it's a linked list of ACL elements arranged in priority order,
plus an IP address table implemented as a modified radix tree.  Whereas
radix trees usually return the closest match in the table, these find the
closest match, then successively walk back through all the less-good
matches until they find a match that has a higher *priority* than the best
match.  (So for instance, address 132.147.67.42 comes in, and there are
rules for 132.147.67/24 and 132.147/16.  The /24 is a better match than the
/16, but if the /16 is what was specified first in the configuration file,
then that's the rule that takes precedence.)

Then there's a linked list of other ACL elements that don't fit into an IP
address table (TSIG keys, nested ACLs containing their own sets of rules,
and dynamically modified ACLs "localnets" and "localhost").  Nested ACLs
get merged into the containing ACL if they're positive, but if they're
negated then they have to be kept separate.  It's all quite weird. 
Fast, though.

-- 
Evan Hunt -- each at isc.org
Internet Systems Consortium, Inc.