Subject: [AAA-WG]: TCP streaming problem

From: David Frascone <[email-masked]>
Date: Sun, 21 Oct 2001 15:02:43 -0500

I have an issue with how reserved bits and invalid attribute lengths are 
handled.

In the spec (08-alpha1), a server is supposed to return a protocol error if
it receives a packet that is malformed.  But, I do not think that simply
returning an error is a good idea (Or, it's not a good idea when TCP is
the transport . . . see below)

Let's suppose the following situation:  As a result of either buggy code,
or in an attempt to be malicious, I send some random bytes to a diameter
server.  Of course, when the errors are detected (via reserved bits set,
or invalid avp lengths), the message (up to that point?) is returned with
an error.  But then what?  How would the server find the start of the next
(hopefully valid) diameter message?

With SCTP (or the old UDP), this problem was moot, since the messages were
guaranteed to arrive in one packet all together.  But TCP is a stream, and
finding the next start of message would be close to impossible.

So, I prepose, in the event of a protocol error that might be caused by a
malicious or broken server, the connection be immediately dropped.  (An 
error packet could be sent first, I guess).  I think this should be a MUST
for TCP, SCTP would be up to the wg.

Comments?