[bind10-dev] ACL Syntax proposal

Warren Kumari warren at kumari.net
Sat May 28 19:13:24 UTC 2011


On May 27, 2011, at 6:08 PM, Evan Hunt wrote:

>> I wrote a proposal how ACL syntax could look like. Could you please have
>> a look at it and tell me if you think this would work, be friendly to
>> users and usable?  Or if you see some minor glitches or think it's
>> completely wrong?
> 
> I'm not sure boolean logic is quite the right approach here (and maybe it's
> not what you had in mind, but the use of AND, OR, and NOT suggests that it
> is).
> 
> Intuitively, boolean expressions *seem* like a good approach, because
> ultimately an ACL does return a yes-or-no answer--but the process of
> getting there isn't quite what you'd expect.
> 
> Admittedly, I've had my mind twisted by working too closely with BIND 9
> ACL syntax, which is... more than a bit weird.  They search for the first
> match not the best match, and they use a kind of three-value logic instead
> of two:  An ACL element can accept, reject, or fail to match (in which
> case we move on to the next ACL element, until we find one that *does*
> accept or reject, and then we stop looking).
> 
> Boolean expressions strike me as an imperfect fit in a couple of ways.
> For example, does "ACCEPT": { "NOT": { "ip": "10/8" }} mean "reject any
> address which is in 10/8" , or does it mean "accept any address which is
> *not* in 10/8" ?  If an ACCEPT block and a REJECT block both matched a
> query, which one would get priority?
> 
> 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).
3: The Checkpoint Way -- this wouldn't really work here -- it involved making objects and then integrating them into rules. It basically needs a GUI.
4: Something else entirely.


Some (contrived) examples:
1: 
ip access-list extended BIND10
 permit udp 10.0.10.0 0.0.0.255 10.0.100.0 0.0.0.3 eq domain
 permit tcp any host 10.1.1.1 eq 22
 permit tcp any host 10.2.4.1 eq 22
 permit tcp any host 10.15.11.5 eq 22
 permit tcp any host 10.19.27.9 eq 22
 deny  ip any 10.0.0.0 0.255.255.255
 permit udp host 192.0.2.1 any
!
This is a cisco style ACL that allows from 10.0.10.0-255 to 10.0.100.0-3 port 53
	then anyone to SSH to 10.1.1.1, 10.2.4.1, 10.15.11.5 and 10.19.27.9
	no other traffic can go to 10.0.0.0/8
	the host 192.0.2.1 can send UDP traffic anywhere
	there is an implicit deny at the end.
this is evaluated in a top-down manner -- so, even though 192.0.2.1 can send traffic anywhere (last line) it cannot send traffic to 10/8 (prevented by line 3), except for those things above.



2: 
filter bind10 {
    term Internal_to_DNS_server {
        from {
            source-address {
                10.0.10.0/24;
            }
            destination-address {
                10.0.100.0/30;
            }
            protocol udp;
            destination-port [ 53 110 25 ];
        }
    }
    term Allow_SSH {
        from {
            destination-address {
                10.1.1.1/32;
                10.2.4.1/32;
                10.15.11.5/32;
                10.19.27.9/32;
            }
            protocol tcp;
            destination-port 22;
        }
        then accept;
    }
    term Block_internal {
        from {
            destination-address {
                10.8.0.0/32;
            }
        }                               
        then {
            discard;
        }
    }
    term My_Host {
        from {
            source-address {
                192.0.2.1/32;
            }
            protocol udp;
        }
        then accept;
    }
}

This is a JunOS style filter that does the same thing -- while much much longer, I think it is much easier to read and understand. The syntax is very very flexible, probably much more so than is needed for this -- but something like a limited subset of the syntax could be used...


Some interesting reading: 
Semantics, implementation and performance of dynamic access lists for TCP/IP packet filtering -- http://www.cs.wits.ac.za/~scott/papers/sacj451.pdf

Performance Characteristics of BDD-based Packet Filters.

S Hazelhurst, A Attar, and R Sinnappan. ‘Algorithms for improving the dependability of firewall and filter rule lists’. In Workshop on the Dependability of IP Applications Platforms and Networks, pp. 576–585, New York, (June 2000). IEEE Computer Society Press. In Proceedings of the International Conference on Dependable Systems and Networks

"Algorithms for Advanced Packet Classification with Ternary CAMs "  --- while this document focuses on TCAMs it contains a bunch of useful info...


W

> 
>                                        eh
> 
> _______________________________________________
> bind10-dev mailing list
> bind10-dev at lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind10-dev
> 




More information about the bind10-dev mailing list