[bind10-dev] ACL Syntax proposal

[JINMEI Tatuya / 神明達哉]

At Sat, 28 May 2011 15:13:24 -0400,
Warren Kumari <warren at kumari.net> wrote:

> On May 27, 2011, at 6:08 PM, Evan Hunt wrote:
[...]
> > I would suggest looking at how router firewall rules are configured for
> > guidance in this.  I don't know how Cisco and the like do it, but I've
> > used ipfw and (ugh) iptables, and like BIND 9 ACLs they also take a
> > first-match appraoch that concentrates on getting a yes/no answer as
> > quickly as possible rather than traversing a logic tree.
> 
> Over the years I believe I have had the honor^w pain of working with
> most network vendors ACL / firewall syntax.
> 
> In general the syntax can be broken up into 4 main categories:
> 1: The Cisco Way -- a large number of folk have copied this. It is
> neither elegant nor friendly, but it *is* simple to implement and
> understood by a large number of folk.

> 2: The Juniper Way -- this is (IMO) elegant, easy to work with,
> somewhat self documenting and clean. While less folk have used it,
> the number is fast increasing, and is (again IMO) easier for a
> newbie to learn (it also seems to lend itself to lex / yacc).

And both are based on the "first-match" approach (or in more general,
the approach where the ordering of rules matters), right?

My question is whether it's just a historical convention which is not
actually user friendly, or it's actually the best (or least bad)
practice we've ended up having.

I'm asking this because one of the responses from our own operators on
this issue was "the lack of ordering is a huge mistake" (the revised
wiki version actually supports ordering-based syntax, too, but the
point I think is which mode is primarily intended).  I'd like to know
which mode is (deemed to be) more operator friendly, and, if known,
whether it's just a convention or based on more profound background.

I'd appreciate it if other operators in this list could provide their
opinion/experiences/preferences.

Hopefully to make it specific, I'll show concrete examples below.
Using your Cisco-style example (tweaking and shortening it a bit for
readability), ordering-centric version of a rule would look like this:

ip access-list extended BIND10
 permit udp 10.0.10.0-255 10.0.1000-3 eq domain
 permit tcp any host 10.1.1.1 eq 22
 deny  ip any 10.0.0.0/8
 permit udp host 192.0.2.1 any
!

Boolean-centric version for the same rule set would be (again, I'm
using a tweaked version of the proposed syntax for readability):

permit {
  OR [
     udp 10.0.10.0-255 10.0.1000-3 eq domain
     tcp any host 10.1.1.1 eq 22
     AND [
       NOT { ip any 10.0.0.0/8 }
       udp host 192.0.2.1 any
     ]
  ]
}

(Both assume an implicit "default deny" policy)

Hmm, as I tried to write this example myself, I found the former
(ordering based version) is more intuitive to me...it's not
immediately clear if the logic of AND-NOT is a correct representation
to implement the intent.  One "advantage" of the latter version is
that we can swap the two sub rules within AND:

     AND [
       udp host 192.0.2.1 any
       NOT { ip any 10.0.0.0/8 }
     ]

but at least in this particular case it doesn't outweigh its drawback
of being less intuitive.

Maybe this is an unfair example that is specifically advantageous for
ordering-based rules, or maybe that's because I'm "too familiar with
the old weird notation" (I've written ordering based filtering rules
for my personal servers or for some routers I used to operate, so I'm
somewhat familiar with that notation.  But in my case they are
basically pretty simple, so I don't think I'm "too" familiar with it).
But one concern I've been having with the boolean approach is that it
may require more brain powers.  To understand and write compound
boolean expressions one needs to have and operate logic stack within
their brain.  Programmers regularly do it in their daily job, so I
suspect we (programmers) tend to underestimate the load.

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