[bind10-dev] ACL Syntax proposal

[Michal 'vorner' Vaner]

Hello

On Fri, Jun 03, 2011 at 12:33:21AM -0700, JINMEI Tatuya / 神明達哉 wrote:
> - I was a bit confused about the syntax in the use of ACCEPT(-IF) and
>   REJECT(-IF).  To me, an ACL rule essentially consists of a function
>   that maps some object (an IP address, DNS message, etc) to boolean
>   values (i.e., "match" or "not match") and associated actions (often
>   "accept", "reject", etc) for the boolean values.  Most of the
>   example syntax shown in the wiki page seems to define such
>   functions.  For example, this one would be considered a function
>   of IP addresses that returns true/false:
> {
> 	"ip": ["192.168.0.0/16", "10.0.0.0/8", "172.16.0.0/12"]
> }

Yes, it's correct, these are functions from packets+their sources into
true/false.

>   But I'm confused when I see this
>   ACCEPT: {"AND": []}

Well, I wanted to say that we provide a „constant“ functions which would be
"ACCEPT" (always returning true) and "REJECT" (always returning false). These
were for completeness and fast short-circuit of some part of the expression or
something like that.

The {"AND": []} thing is possible implementation of such rule. As, by
definition, AND returns true if all its subexpressions return true, this one
returns true always. Maybe this one confuses more than clarifies, but I wanted
to show the „extremes“ of the behaviour.

>   or even this:
>   {"ACCEPT-IF": {"ip": "132.147.67.16"}}
>   This seems to indicate that a JSON object that contains ACCEPT(-IF),
>   etc, is also a part of "function".

Well, this is slightly more complicated. Each check is allowed to understand its
value as it likes. So, while AND and OR eat just the list brackets and delegate
the rest to subexpressions, the FIRST-MATCH operator needs more information.
Therefore, it goes and looks at the elements in its list one by one. Each
element contains a condition and what to do if it matches. So, if we have an
element like in your example, this will check if the IP address is the one given
and if so, it will just return true for the whole FIRST-MATCH. If it does not
match, it continues with the next expression.

>   I think I understand the general concept of the proposal, but to be
>   fully sure and to be able to implement it, I'd like to see some
>   level of formal definition of the syntax.

Well, as I said. We start matching from outside, the dict contains name-value
pairs. The name says what kind of check it should be and the value completely
belongs to the check, it is free to have it structured in any way. Some rules
can extract bit of it and say that these are smaller expressions, so they are
matched from their outside again. But the high-level syntax doesn't say where
the subexpressions should be placed inside the type-dependant structure.

Then each type defines its syntax. The NOT contains the subexpression directly,
OR and AND contain list of them and the FIRST-MATCH contain kind of sequential
program, each command being a condition and what result should the whole
FIRST-MATCH return when the condition is met.

> - Regarding TSIG, in BIND 9 we only use key names in ACLs.  (As I
>   thought documented somewhere in the wiki proposal) TSIG check will
>   be performed independently from ACLs, I think it's reasonable to
>   only consider whether TSIG is included, and if so, which key name is
>   used.  Note also that in that case TSIG matching in the ACL may not
>   be that expensive (in fact, if we identify TSIG keys in an efficient
>   way such as unique integer identifiers, it may be even more
>   lightweight than IP address/prefix matching).

Ah, OK. That was an example of what checks may exist. Having it like this is
fine:

{"TSIG": "key_name"}

> - Maybe related to the first point, we'll often want to specify a rule
>   like "accept something from this source address".  How would such a
>   rule look like in this proposed scheme?

I'm not sure what you ask. Like a rule that accepts packets from only single IP
address? It would be:

{"ip": "1.2.3.4"}

(Returning true for this one and false for anything else).

With regards

-- 
Wait few minutes before opening this email. The temperature difference 
could lead to vapour condensation.

Michal 'vorner' Vaner
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <https://lists.isc.org/pipermail/bind10-dev/attachments/20110603/2edbca9f/attachment.bin>