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

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

3118 seems to be pretty clear in that it acknowledges that option 82 may be
present, and that the signature is to be calculated: "the server MUST
compute any hash function as if the option were NOT included" (section 3).
However 3118 does make a bad mention of option 82 being the last option in a
message (also in section 3).  I'd assume that it means that option 82 is
taken completely out of the packet, and the packet is compressed by those
bytes (as opposed to being filled by Pad options).

In either case, I'd still call the relay buggy since in the definition of
the End option (RFC 2132, section 3.2) it states "The end option marks the
end of valid information in the vendor field.".  Thus a strictly complying
server cannot rely on anything that appears after the End option.

If the End option is in the message, I'd expect it to be included in the
hash.

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.

-----Original Message-----
From: Ted Lemon [mailto:[email-masked]]
Sent: Tuesday, September 16, 2003 12:04 PM
To: [email-masked]
Subject: [dhcwg] An unfortunate ambiguity in RFC3118/RFC3046...

We have encountered in the field a relay agent that does something 
interesting.   RFC3046 says that the relay agent is supposed to insert the 
Relay Agent Information option into the packet at the point where the End 
option in the packet was found, or at the end of the options.   This client 
ignores RFC3046 and stores the Relay Agent Information option _after_ the 
packet's End option, followed by its own End option.

Our first reaction was to think that the relay agent was just buggy, but I 
went and looked at the RFCs and discovered a problem, which this relay agent

actually doesn't hit because of its weird way of storing the option.

The problem is that what RFC3046 says about the End option is ambiguous with

respect to figuring out what the packet looked like when the RFC3118 
signature was computed.   Consider the following scenarios:

1. The packet has an End option after the last informative option (by which
I 
mean an option that conveys information, as opposed to an End or Pad
option).

2. The packet has no End option, and has some number of bytes of Pad options

after the last informative option.

3. The packet has no End option, and no Pad options after the last
informative 
option.

It could be argued that (2) and (3) violate section 4.1 of RFC2131, which
says 
"The last option must always be the 'end' option."   However, people have 
interpreted this in different ways - does this mean that the packet MUST
have 
an End option, or does it mean that if the packet has an End option, it MUST

be the last option in the packet?   What should the sending agent do when it

has exactly enough options to fill the option buffer, and no room for an End

option?   Does it send the End option, or not?

So although cases (2) and (3) are technically out of spec, I would say that
we 
should account for them.   Even in case (1), it's not clear what to do.   Is

the End option included in the signature, or no?

I think we need some language to explicitly say what relay agents should do
in 
all of these cases, and also what sending agents should do in these cases.

Comments?

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

---

From: Ted Lemon <[email-masked]>
Date: Tue, 16 Sep 2003 16:47:54 -0500

> If the End option is in the message, I'd expect it to be included in the

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?

> 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.