[bind10-dev] when should we apply ACL in incoming request processing?

[Shane Kerr]

Jinmei,

On Fri, 2011-06-24 at 11:32 -0700, JINMEI Tatuya / 神明達哉 wrote:
> I had a couple of things I was not sure about when I worked on #999
> (b10-resolver ACL):
> 
> 1. The default ACL
> 2. At which point in incoming request process we should apply the ACL
> 
> In the current code (now under review), the default is "accept ::1 and
> 127.0.0.1 and rejects others (returning REFUSED)".  This is probably
> reasonable, especially because the default listen_on is also ::1 and
> 127.0.0.1.  (But if someone had a different opinion I'd appreciate
> other suggestions)

The only question about the default ACL is whether it makes more sense
to DROP the packet on the floor rather than returning REFUSED. I prefer
REFUSED, but I thought I'd point out the option. (It may depend on what
happens below...)

> I'm more uncertain about the second point.  The current implementation
> applies the ACL after:
> - parsing the incoming packet (which may result in FORMERR if the
>   packet is broken in some specific ways),
> - refusing unsupported opcode (anything other than normal query for
>   the resolver) with NOTIMP (or NOTAUTH for notify), and
> - refusing a query containing more than one question (with FORMERR)
> 
> So, for example, even if the administrator specifies an ACL rule that
> drops/rejects queries from a specific IP address, the resolver still
> performs the above checks and could return FORMERR, NOTIMP, etc.
> 
> This is compatible with BIND 9's behavior, but I guess administrators
> would rather reject an unwanted packet before doing any deeper
> inspection.  BIND 9 actually has a separate "blackhole" ACL, which is
> applied before doing any protocol level processing, but the current
> implementation of b10-resolver doesn't have an equivalent to that.

There is a further benefit, which is that if someone writes custom BIND
10 code they may introduce some coding bug in packet parsing, for
example. (Okay, in principle we could also introduce such code.) If this
code is invoked after the ACL checks, then only more trusted users will
ever invoke the code.

> Note that simply applying ACL before doing anything may not really be
> the best except for "blackhole"ing because we could return a REFUSED
> response to a packet that may not even be a DNS message (but is
> somehow delivered to the server).

One drawback to using REFUSED before parsing is that it makes
amplification attacks that much easier. I like Stephen's idea of
dropping malformed packets for that reason.

> Blackholing (in our current terminology, "DROP") may also be
> suboptimal in that it could make the client repeat the query
> unnecessarily.
> 
> So, what should we do?  Any opinions?

As Michal mentioned, we don't have much flexibility at certain points of
the processing.

We have these options, right?

      * We could introduce an ACL before any parsing is done, this
        cannot check packet internals, and can only be used to DROP
        packets.
      * We could introduce an ACL after parsing is done, but before the
        3 checks described. This can both REFUSE and DROP packets.

Perhaps we should make a flow-chart for administrators that explains
what is checked where in processing?

--
Shane