[bind10-dev] ACL Syntax proposal

[JINMEI Tatuya / 神明達哉]

At Fri, 3 Jun 2011 11:27:12 +0200,
Michal 'vorner' Vaner <michal.vaner at nic.cz> wrote:

> On Thu, Jun 02, 2011 at 06:10:36PM -0700, JINMEI Tatuya / 神明達哉 wrote:
> > Maybe this is an unfair example that is specifically advantageous for
> > ordering-based rules, or maybe that's because I'm "too familiar with
> 
> Some other example could be, we have 3 trusted peers, each one with IP
> address and TSIG key, we allow to do anything, private subnets where we allow
> recursion and we allow authoritative queries from everywhere.
> 
> So, we start ‒ there are 3 „groups“, these would form an or. One would be the
> authoritative query, which would look like (for example):
> 
> {
>   "rd-bit": false,
>   "opcode": "query"
> }
> 
> Another one would be the recursive one:
> 
> {
>   "opcode": "query",
>   "ip": ["10.0.0.0/8", "192.168.0.0/16", "172.16.0.0/12"]
> }
> 
> And a block for each of the peers, like:
> 
> {
>   "ip": "1.2.3.4",
>   "tsig": "first-key"
> }
> 
> {
>   "ip": "5.6.7.8",
>   "tsig": "second-key"
> }
> 
> ...
> 
> And as they are independent, we put all of these into one big OR.
> 
> 
> With the first-match, we still need some way of having and operator. Because we
> need to do things like
> 
> * 1.2.3.4 and tsig → accept
> * 5.6.7.8 and tsig → accept
> * query and 10/8 → accept
> * query and 192.168/16 → accept
> * query and rd-bit = false → accept
> * reject
> 
> This takes me more work to think about the ordering and I'm not completely
> shielded from boolean expressions either.

Using BIND 9's analogy (not to mean we should definitely follow it in
BIND 10), we'd actually separate these rules in places where they are
applied.

query { // for b10-auth
  allow any;
  // or we could say (although I suspect this "rule" is not something 
  // supposed to be in an ACL)
  // query and rd-bit = false 
};

transfer { // for b10-xfrout
  allow 1.2.3.4 and tsig
  allow 5.6.7.8 and tsig
};

recursion { // for b10-auth
   accept 10/8
   accept 192.168/16
};

And, in practice, I don't see much trouble in this "ordering-based"
way.

Again, to clarify my position, I personally don't object to the idea
of boolean based rules (or the idea of having them primarily with
supplemental "first-match" extension) per se.  But as a real operator
showed a strong preference for the ordering based one, if we want to
sell the new idea, we need to show a convincing, practical example of
how the new rule is wonderful and convince they should rather use it.
So far, I don't think I've seen that level of convincing proof, and if
I were a stubborn "who is always reluctant to learn new things (as
generous developers tend to say)", I'd oppose to introducing it.

---
JINMEI, Tatuya
Internet Systems Consortium, Inc.