Subject: RE: "Michael W. Patrick": dhcp agent options draft 12

From: Bernie Volz <[email-masked]>
Date: Wed, 25 Oct 2000 16:28:26 -0400

Thomas:

I think the present wording is OK as it doesn't say to zero those fields out
- it says to REMOVE the option as it if were not present (it DOES say to
zero the 'giaddr' and 'hops' fields since they were zero when the
authentication was calculated).

Certainly if YOU think the wording "if the option were NOT included" is
confusing and open to interpretation, then we could change it.

- Bernie Volz

-----Original Message-----
From: Thomas Narten [mailto:[email-masked]]
Sent: Wednesday, October 25, 2000 3:48 PM
To: DHCPv4 discussion list
Cc: DHCPv4 discussion list; [email-masked]
Subject: Re: "Michael W. Patrick": dhcp agent options draft 12

Bernie Volz <[email-masked]> writes:

> In RFC 2131, in section 4.1 it states:

>    DHCP clients and servers both construct DHCP messages by filling in
>    fields in the fixed format section of the message and appending
>    tagged data items in the variable length option area.  The options
>    area includes first a four-octet 'magic cookie' (which was described
>    in section 3), followed by the options.  The last option must always
>    be the 'end' option.

> And, in RFC 2132, section 3.2 defines the 'end' option:

> 3.2. End Option

>    The end option marks the end of valid information in the vendor
>    field.  Subsequent octets should be filled with pad options.

>    The code for the end option is 255, and its length is 1 octet.

Got it. What had confused me was the reference above to "in the vendor
field". RFC 2131 uses "options" and the "vendor field" terminology
dates back to bootp.

"Michael W. Patrick" <[email-masked]> writes:

> I checked the Auth draft, and it explicitly
> says to include all options in order EXCLUDING any relay
> agent options (type 82) that may be present.  So the
> auth draft doesn't care where the 82 option is (either
> before or after END).  The auth draft does, however, care
> very much whether the END option got stripped, because the END is
> included in the authentication.

reading the text in <draft-ietf-dhc-authentication-14.txt:

3. Interaction with Relay Agents

   Because a DHCP relay agent may alter the values of the 'giaddr' and
    'hops' fields in the DHCP message, the contents of those two fields
   MUST be set to zero for the computation of any hash function over the
   message header. Additionally, a relay agent may append the DHCP relay
   agent information option 82 [7] as the last option in a message to
   servers. If a server finds option 82 included in a received message,
   the server MUST compute any hash function as if the option were NOT
   included in the message without changing the order of options.

It seems like the above wording might benefit from some tweaking. It
isn't enough to just zero out the agent option fields. It needs to be
removed and the end option shifted to take its place (and the length
of the packet over which the computation is performed needs to be
adjusted). I.e., the authentication check will fail unless its run
over the exact packet that was sent before the relay agent options got
added (and now, its not just appended, but inserted before the end
option). Make sense?

Thomas

---

From: Thomas Narten <[email-masked]>
Date: Thu, 26 Oct 2000 06:18:18 -0400

> authentication was calculated).

I agree that the wording is technically correct.

> confusing and open to interpretation, then we could change it.

My take is that an ounce of prevention is worth ...

There seems to be lots of experience that if there is any way for
someone to become confused about part of a spec, SOMEBODY inevitably
will... :-)

Thomas