BIND 10 #2600: DHCP Testing: V4 features - robustness

[BIND 10 Development]

#2600: DHCP Testing: V4 features - robustness
-------------------------------------+-------------------------------------
            Reporter:  stephen       |                        Owner:  tmark
                Type:  task          |                       Status:
            Priority:  medium        |  reviewing
           Component:  dhcp          |                    Milestone:
            Keywords:                |  Sprint-DHCP-20130411
           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 marcin):

 * owner:  marcin => tmark


Comment:

 Replying to [comment:6 tmark]:
 > I reviewed your analysis of the expected responses and replied to each
 below. There is, as you point out room for interpretation and there are
 currently no statements of the  requirements nor is there informal
 consensus as to what is and is not correct.
 >
 > The level of effort involved to determine what the proper behavior based
 on
 > packet content is beyond the scope of this ticket. Therefore, two new
 tickets
 > have been created:
 >
 > 1. 2889 Derive requirements from RFC2131, Section 4.3
 > 2. 2890 Resolve disparities between ISC_DHCP and b10-dhcp4 in packet
 handling
 >
 > to codify the requirements against which to test and reconcile
 disparities
 > between ISC_DHCP and b10-dhcp4 responses.
 >

 That's good. Thanks for this.

 >
 > > (Test Cases):
 > > I verified correctness of these test cases by referring to RF2131,
 section 4.3.2.
 > >
 > :
 > >
 > > As to the last test case... The inbound packet in test procedure is
 DISCOVER, while in the script it is REQUEST. Which one was intended?
 >
 > It is a REQUEST, the script is correct.  The procedure text has been
 corrected.
 >
 > >
 > > I think it might be worth to add some test cases that involve
 returning clients. So, for example:
 > > - scapy initiates normal 4-way exchange and obtains a lease
 > > - scapy initiates REQUEST with valid server id etc. but with invalid
 address
 > >
 >
 > Case 1, that Kea should either NAK or not respond, depending upon
 > interpretation. Currently, it responds with an offer.  ISC_DHCP responds
 with
 > a NAK.
 >

 I recall that there used to be a ticket against this issue? Which one was
 it? Perhaps we could update it saying that there are two interpretations
 of the RFC and they should be considered before implementing this ticket.
 These interpretations are: send NAK or remain silent.

 > Case 2, ISC_DHCP responds with an offer, same as b10-dhcp4.
 >

 This will need to be revisited when we are done with #2889 and #2990?

 > Case 3, ISC_DHCP does not find a matching lease, does not respond to
 case 3. Kea responds with an offer.
 >
 > I agree we need more tests here. We are also going to need some
 consensus on correct behavior.
 >
 >
 > > '''v4.malformed_packets.1.txt'''
 > > The same comments apply as for the other test procedures.
 > >
 > > The interpretation of specific test cases....
 > >
 > > (1.) The blank chaddr is in this case 00:00:00:00:00:00. This is in my
 opinion valid HW ....

 Overall, we agreed that further discussion is required on interpretation
 of RFCs and the result of this should be reflected in our tests.
 Therefore, I think it is ok to close this particular ticket and correct
 tests once we reach consensus on interpretations.

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