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

From: Ted Lemon <[email-masked]>
Date: Tue, 16 Sep 2003 14:03:53 -0500

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: Bud Millwood <[email-masked]>
Date: Wed, 17 Sep 2003 11:43:03 +0200

On Tuesday 16 September 2003 21.03, Ted Lemon wrote:

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

(2) and (3) are common enough in practice, in my experience. A server should
definitely handle these interpretations of the End option.

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

I've thought about this in the past, and it's easy enough to write a server
that handles either interpretation. But it's ambiguous for a client author,
because you don't know if you can pack your buffer with that last option and
"get away with" not sending an End option; you can't be sure the server will
accept it, although in practice it positively should.

If I were to change the RFC to help client authors when making this decision,
I'd make it acceptable to not have an End option if there's exactly enough
room to fit the options. In all other cases I'd make it mandatory.

> Even in case (1), it's not clear what to do.
> Is the End option included in the signature, or no?
>
> 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?

The End option is a valid option. I don't see why it would not be included in
the hash.

Also, I think Andre's comment about the relay agent not being able to add an 
end option is square on: you can't just add that option as a relay agent.

If, as a relay agent, you find that you would have just enough room to insert
option 82 if you left out the originator's End option, you're out of luck;
End option is a legitimate option, and you are not allowed to remove it.

RFC 3046 makes a special exception for the end option by saying "(but before 
'End Option' 255, if present)", but that doesn't imply any other special
treatment, such as being able to remove the option altogether.

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

I don't think RFC 3046 is ambiguous about handling of the End option, but it 
can't hurt to clarify the status of the End option if enough agent authors 
are getting it wrong. As for client authors, I do think it would be good to 
clarify when you can leave out the End option.

When you said above:
> 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.

What I missed in this was how the relay agent you found can in any way
 justify placing option 82 *after* the End option. You're not saying it's
 justifiable, you're saying it will never result in an incorrectly computed
 RFC 3118 hash value, right? But if the relay agent knows that it's not at
 liberty to remove any present End option, regardless of the circumstances,
 then there should not be a problem.

That said, we discussed this here and are wondering about the behaviour of a
relay that extends the original packet when the original packet does not have
an End option. The computed hash value would then be including n extra bytes
that the relay agent expanded the message by (although those bytes should be
zero).

Is this a problem? It seems that from a purely technical perspective, the
server should never compute bytes that were not part of the original message.
But without an end option, there's no way of knowing where to stop
computation. If the hash function doesn't rely on the length of the original
packet, that's good, but shouldn't it be stated explicitly that Pad options
should not affect the hash value?

Another suggestion could be to add a new suboption to option 82 denoting the
original length of the packet.

Regards,

Bud Millwood
Weird Solutions, Inc.
http://www.weird-solutions.com
tel: +46 8 758 3700
fax: +46 8 758 3687
mailto:[email-masked]