BIND 10 #2600: DHCP Testing: V4 features - robustness
BIND 10 Development
do-not-reply at isc.org
Wed Mar 27 13:09:51 UTC 2013
#2600: DHCP Testing: V4 features - robustness
-------------------------------------+-------------------------------------
Reporter: stephen | Owner:
Type: task | marcin
Priority: medium | Status:
Component: dhcp | reviewing
Keywords: | Milestone:
Sensitive: 0 | Sprint-DHCP-20130328
Sub-Project: DHCP | Resolution:
Estimated Difficulty: 0 | CVSS Scoring:
Total Hours: 0 | Defect Severity: N/A
| Feature Depending on Ticket:
| Add Hours to Ticket: 0
| Internal?: 0
-------------------------------------+-------------------------------------
Changes (by tmark):
* owner: tmark => marcin
Comment:
Replying to [comment:5 marcin]:
> Reviewed commit 43322ef85b573c27ae669d35dc52d8e06d75a928
>
> '''Gerenal comment''': As in the case of #2607 I would suggest to avoid
using examples of configuration but rather mandate use of the
172.16.1.0/24 subnet and add a comment saying that it can be changed if
this configuration does not fit into the environment used to execute the
test. However, it should be noted that configuration file must be changed
accordingly.
>
Done
> '''v4.valid_only.1''':
> (1.3): The following address 172.16.1.1 is reserved to the server, the
172.16.1.4 is reserved for the relay. Thus, the configured address pool
should exclude these addresses so as they are not assigned to the
requesting client. Although, it may not be a harm here because scapy would
not assign any addresses to the interface but as a general rule it is
probably better to avoid situations when the server leases his own address
to the client. Note, that there may be some real clients in this network
and they may !''accidentally!'' request address from the server under
test.
>
Done
> (3.): This section should give more detailed instructions how to run the
client with scapy. Ideally, the exact command line is specified which
redirects the contents of the python script to scapy. Alternatively, the
text could mention that the script contents needs to be copied over to the
interactive shell.
> Also, the script assumes that my interface is called !''vlan6!'' which
in most of the time is not the case. There is no step in the test
procedure that instructs to replace the default interface name with my
interface name. Same applies to the address to be configured for the
interface.
>
Added small shell script, run_packet_tests.sh, which makes it painless to
execute the
tests addresses the "vlan6" issue.
> '''v4.improper_addresses.1.txt'''
> The comments for the previous test apply here too.
>
Done.
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.
> (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.
Case 2, ISC_DHCP responds with an offer, same as b10-dhcp4.
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 address so the server should respond with OFFER which it
does. Maybe more interesting case would be to include no HW address at
all?
>
Agree. (ISC_DHCP responds with an offer.)
> (2.) The giaddr blank is as it was not going through relay. The blank
(zeroed) HW address is a valid HW address so OFFER response is probably
valid. Also, it is a direct, not broadcast traffic coming out from client
but it is allowed by the RFC 2131.
>
Agree. (ISC_DHCP responds with an offer.)
> (3.) Client MUST include 'END' option. If it doesn't the packet is
malformed should be probably dropped. This fact could be logged to notify
administrator. It is up to further discussion whether we want the server
to be strict or not.
>
> (4.) In the section 3. of RFC 2131 it is mentioned that client uses
opcode 1 and the server uses opcode 2. The RFC does not use !''MUST!''
here so it is hard to say whether it is a strict requirement. However,
based on our discussion on jabber it may be worth to start with strict
rules for our server and maybe become less strict if required. I would say
that this is malformed packet that should be dropped.
>
I agree it is malformed, but should we drop it? (ISC_DHCP responds with
an offer.)
>
> (5.) According to RFC 2131, section 4.3.1. If the requested address is
invalid, server allocates new address from the pool in response to
DISCOVER. So, OFFER is expected response in my opnion.
>
Agree. (ISC_DHCP responds with an offer.)
> (6.) By setting flags to 0xFFFF you're setting reserved bits which MUST
be zero according to section 2 of RFC 2131. Thus, the packet is malformed
and should be dropped in my opinion.
>
Subject to debate.
per RFC 2131, page 10, end of Section 2.0
"They MUST be set to zero by clients and ignored by servers and relay
agents. Figure 2 gives the format of the 'flags' field."
which could be interpreted as "They MUST be ignored by servers and relay
agents", therefore responding with an offer is correct(ISC_DHCP responds
with an offer).
> (7.) Server was unable to parse the malformed packet so no response is
probably expected behavior.
>
Curiously, ISC_DHCP can parse this one and extends an offer.
> (8.) According to RFC 3046, section 2.2. the server may be unaware of
the Agent Information Option. Thus, it is not even obliged to echo it back
to the relay. The fact that the sub-option of AI Option is broken is not a
problem because server doesn't have to interpret the option contents so it
will never discover that it is broken. In this case, it is ok that the
server responds with OFFER.
>
Your argument seems reasonable, however ISC_DHCP fails to parse this one,
"malformed option agent.<unknown> (code 98): option length exceeds option
buffer length) and drops it.
> (9.) IMHO, it is ok to request unassigned/non-standard options. Note,
that DHCP implementations allow to define proprietary options. Suppose
that there is new DHCP standard released which introduces option X. The
server implementation may not support this option natively, so the
administrator may want to create option definition using configuration
mechanism to start using it until support is not added into the code.
> If option definition is not yet configured it is ok that client asks for
this option anyway. He will get it once it is configured. As long as it is
not configured he will get everything else but this option. So again,
OFFER is ok.
>
Agree. (ISC_DHCP responds with an OFFER).
> (10.) The minimum length of the Root Path option is 1. In this sense,
the packet is malformed and assuming strict validation rules it should be
dropped.
>
ISC_DHCP responds with an offer. Again this comes down to what do we
enforce?
> (11.) Lack of response seems to be ok.
>
Agree. ISC_DCHP logs no such lease and does not respond.
> (12.) I would say that server should ignore this request. The client
neither includes requested IP address nor server id. This fits to the case
described in RFC 2131, section 4.3.2, bullet !'' DHCPREQUEST generated
during RENEWING state!''. Unfortunately, this section does not say what
server should do if there is no record of the client (which is the case
here). But hey! If it doesn't have the record of the client then probably
other server had given him a lease he is trying to renew. Then, the best
thing to do is do not respond. NAK is probably inappropriate because it is
used to decline the address being requested. But here, we don't request
address. Server should not respond to it in my opinion.
>
> ----
This one is actual a duplicate of test case 3 (which was mislabeled as a
DISCOVER) in improper addresses and has been deleted from mal-formed set.
However, your interpretation is still valid and concurs with ISC_DHCP's
behavior.
--
Ticket URL: <http://bind10.isc.org/ticket/2600#comment:6>
BIND 10 Development <http://bind10.isc.org>
BIND 10 Development
More information about the bind10-tickets
mailing list