Subject: RE: [dhcwg] An unfortunate ambiguity in RFC3118/RFC3046...

From: "Kostur, Andre" <[email-masked]>
Date: Tue, 16 Sep 2003 16:04:28 -0700

The relay isn't allowed to add extra options other than 82 to a packet.
Thus if an end option exists, it must have been placed there by the
originating device (the one performing the original hash).  Section 4.1.1 of
RFC 1542: "All other BOOTP fields MUST be preserved intact.".  Which is
somewhat overridden by Section 2.1 of RFC 3046: 

   A DHCP relay agent adding a Relay Agent Information field SHALL add
   it as the last option (but before 'End Option' 255, if present) in
   the DHCP options field of any recognized BOOTP or DHCP packet
   forwarded from a client to a server.

Interesting to note that 3046 acknowledges that a client may not have
supplied an End option.  But it does not say that the relay is allowed to
add an End option if one doesn't already exist.  It only allows for the
addition of option 82 as the last option in the packet, but before the End
option "if present".  And 3118 doesn't have anything to say about option 82,
since it's not supposed to be there by the time the end client receives the
packet.

-----Original Message-----
From: Ted Lemon [mailto:[email-masked]]
Sent: Tuesday, September 16, 2003 2:48 PM
To: Kostur, Andre
Cc: [email-masked]
Subject: Re: [dhcwg] An unfortunate ambiguity in RFC3118/RFC3046...

On Tuesday 16 September 2003 14:41, you wrote:
> If the End option is in the message, I'd expect it to be included in the
> hash.

But how do we know which device put it there?   What if the relay agent put
it 
there?   How does the receiver verify the signature?

> As for the presence/absence of the End option, our DHCP server will honour
> it if it is there (and stop reading anything past it), or assume that the
> end of the packet is the end of the options.

I think this is the right behavior for the server, but it doesn't resolve
the 
ambiguity I described.

---

From: Ted Lemon <[email-masked]>
Date: Tue, 16 Sep 2003 21:19:45 -0500

On Tuesday 16 September 2003 18:04, Kostur, Andre wrote:
> option "if present".  And 3118 doesn't have anything to say about option
> 82, since it's not supposed to be there by the time the end client receives
> the packet.

Right, my point is that right now the protocol specifications are ambiguous.   
That doesn't mean that a reasonable person can't guess what they mean.   It 
means that two reasonable people might independently make different guesses.   
This is the problem.   This is what I want to fix.   Are you saying that this 
is not worth fixing?

_______________________________________________
dhcwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/dhcwg