BIND 10 #998: IP based ACL check

[BIND 10 Development]

#998: IP based ACL check
-------------------------------------+-------------------------------------
                   Reporter:         |                 Owner:  jinmei
  vorner                             |                Status:  reviewing
                       Type:  task   |             Milestone:
                   Priority:  major  |  Sprint-20110628
                  Component:         |            Resolution:
  Unclassified                       |             Sensitive:  0
                   Keywords:         |           Sub-Project:  DNS
            Defect Severity:  N/A    |  Estimated Difficulty:  5.0
Feature Depending on Ticket:         |           Total Hours:  0
        Add Hours to Ticket:  0      |
                  Internal?:  0      |
-------------------------------------+-------------------------------------

Comment (by jinmei):

 Replying to [comment:10 vorner]:

 > The notification caught my eye, so I had a short look.
 >
 > Replying to [comment:9 stephen]:
 > > The class as implemented here is only a single ACL match (or non-match
 - the capability to check for a non-match was trivial, which is why I
 added it to this class).  The ACL you are suggesting in the example is
 really a combined ACL:
 >
 > The non-match, I guess, will not be used, for consistency. We probably
 will have a general not, so having a different syntax for not on IP seems
 strange.

 Yeah, that's another point I wondered about, too (but I didn't go into
 that in my previous comment).  Basically, I agree that it makes more
 sense to have generic "NOT" than implementing the negation concept in
 each derived class.

 > > {{{
 > > allow (source matches 2001:db8:1::/64) AND (dest matches
 2001:db8:2::/64)
 > > }}}
 > > I would see then implementation as being a class containing two
 IPCheck classes, one for source and one for destination. It would be the
 container class that knows the structure of the packet and distinguishes
 between source and destination address.
 >
 > But I don't see a way to say „use this context and extract the source
 address“ for one version and „use the same context, but extract the
 destination address“. Maybe it's there, but I didn't notice it.

 I'm not sure if I catch the context correctly, but as I noted in my
 previous comment message, I would envision the above to be implemented
 as follows:

 - (source matches 2001:db8:1::/64) is represented as a single IPCheck
   object that internally stores the information that it's about source
   address
 - (dest matches 2001:db8:2::/64) is represented as a single IPCheck
   object that internally stores the information that it's about
 destination
   address
 - the entire "(source ...) AND (dest ...)" is represented as a kind of
   compound Check object, which consists of the two IPCheck objects,
   and its match() method returns true iff both of the two
   IPCheck::matches() true.
 - The "Context" is a some kind of "Packet" class object, which has the
   ability to extract the source and destination addresses of the
   packet.

 We'd then implement IPCheck<Packet> class, whose matches() method
 would look like this:

 {{{
 bool
 IPCheck<Packet>::matches(const Packet& packet) {
     if (getAddressType() == IPCheck::SOURCE) {
        return (compare(packet.getSourceAddr()));
    } else {
        return (compare(packet.getDestinationAddr()));
    }
 }
 }}}

-- 
Ticket URL: <http://bind10.isc.org/ticket/998#comment:11>
BIND 10 Development <http://bind10.isc.org>
BIND 10 Development