BIND 10 #2326: Allocation engine v6: release

[BIND 10 Development]

#2326: Allocation engine v6: release
-------------------------------------+-------------------------------------
            Reporter:  tomek         |                        Owner:  tomek
                Type:  task          |                       Status:
            Priority:  medium        |  reviewing
           Component:  dhcp6         |                    Milestone:
            Keywords:                |  Sprint-DHCP-20130103
           Sensitive:  0             |                   Resolution:
         Sub-Project:  DHCP          |                 CVSS Scoring:
Estimated Difficulty:  0             |              Defect Severity:  N/A
         Total Hours:  0             |  Feature Depending on Ticket:
                                     |          Add Hours to Ticket:  0
                                     |                    Internal?:  0
-------------------------------------+-------------------------------------
Changes (by stephen):

 * owner:  stephen => tomek


Comment:

 Reviewed commit 72beaf8964363734d4f5e7b4b11ae7b8b4b5557c.

 I've pushed another change to dhcp6_messages.mes.

 Some comments:

 > Because the reason for this is unknown. Just wiping it out would
 potentially mask a problem.
 Fair enough

 >> Line 780: suggest that this be a DEBUG message - a malicious client
 could trigger a flood of warning messages by sending release messages for
 random addresses. (It is assumed that by default, WARNING messages are
 enabled and DEBUG messages disabled.)
 > I disagree. This is a (serious) violation of RFC and we should log it.
 Nobody would notice a log on DEBUG level. I've lowered message severity to
 INFO. Does it look acceptable?

 Given that we log so few conditions, it's probably not a major issue.  The
 general concern for all BIND 10 is that any message that can be generated
 by a packet received from a user can be used as a DoS vector.  Although
 messages can be disabled, disabling all warning messages could mask other
 warning conditions related to the server.  Logging such messages with
 DEBUG severity is one solution:the other is to use a different logger (see
 src/lib/log/README - and before you ask, ticket #2566 has been created to
 convert this to Doxygen format for inclusion into the developer's guide).

 I've posted a message to bind10-dev to see which of the two solutions (if
 either) has been used for the DNS.  I suggest reverting it back to a
 warning (so that it is easier to find again) and we'll revisit this once
 there has been some discussion of the post.

 > So what would the mysql backend do, if it has access to the database in
 read-only mode?
 Read-only access to a database is set up by only restricting the user
 under which the connection is made to SELECT privilege only.  As a result,
 a delete operation will fail, even if the WHERE clause is such that no
 rows are selected for deletion.

 All OK, please merge after changing the message back to a warning.

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