Feedback is much appreciated!

On Oct 23, 2005, at 9:17 PM, Zed A. Shaw wrote:

> 1) Define the official line ending.  This is important since most IETF
> protocols end lines with \r\n.  For the rest of this I assume \n.

Good call, this has been left hanging while discussing the other issues.

> 2)  Header is changed to be:  SIZE COMMAND\n with SIZE being a decimal
> string of the byte size of the HEADER portion immediatly after this
> line.

What will this buy other than making it easier to implement a client?

> 3)  Specify that the first line is never longer than X bytes.  This is
> important as a classic DOS attack is to "trickle" characters forever
> never giving the \n.  If you explicitly state that it can't be longer
> than say 128 characters then servers can boot bad clients quick.

Very good point, thank you!

> 4)  The SIZE of the header specifies the exact length, and removes the
> need for the \n\n separator.  This is also important because I can  
> boot
> a client that tries to send more than SIZE or that says it's going to
> send a SIZE that I don't want.  This prevents another attack where I
> just trickle header lines until the server croaks.

see next response.

> 5)  Require that the header MUST have the content-length settings.   
> This
> is again to make sure that requests which are too large are always
> booted.  Making this optional just leaves open an attack where you
> again slam the server with never ending data until it dies.  This also
> makes it very clear how the content is always sent and leaves nothing
> open for debate.

I disagree with this -- you can bring down a naive server  
implementation with or without this change -- just slam data into  
whatever buffer is accumulating it until it croaks -- almost every (I  
would say every but I don't know for a fact) JMS implementation  
available does a full read for messages which are not of type Stream  
(which is an option for huge messages).

This change does leave open the option for rejecting messages which  
promise to be over the declared size, which is a non-trivial benefit.

> 6)  State that the header has an exact format of "key: value\n" and
> that the value goes from the space after the ":" until \n always.   
> Even
> other ":" characters are included.

This is how it is, other : characters are allowed and the space is  
not required, but is allowed (and trimmed)

> 7)  State that ":" is not a valid header.  This means that they can't
> send empty headers.

What is wrong with an empty header? It wastes bytes, but then so does  
a long message.

foo:
bar:
baz:

all are headers with empty values

:

is bizarre, and wastes a little bit of space, but doesn't *hurt* the  
protocol. In a defensive server, it would be fair to consider it a  
potential attack and consider dropping the client. I am not sure  
specifying this behavior adds anything to the spec except "oh yeah,  
make sure of this" for implementors.

HTTP and SMTP also allow these attacks ... certainly folks have had  
to do a lot of work to prevent DOS attacks such as you describe, and  
preventing them in the protocol is a pretty good suggestion.

> 8)  Also state that clients SHOULD be booted immediately if they don't
> follow these rules exactly.  I really don't like protocols that try to
> be "nice to users".  These protocols are actually just leaving things
> open for attackers to exploit.  In the end "users" do not write
> clients, developers do and being explicit about everything makes it
> easier for them.  This also makes it easier for server implementers to
> boot bad clients without any excuse reducing their attack vectors and
> improving their chances of withstanding DOS attacks.

Good point.

> Anyway, that's just my opinion on it.  Take it or leave it.

Happily take it!

Your points which I have disagreed with I believe I see your point,  
and do not wholeheartedly disagree -- one of core design principles  
has been allowing for telnet clients a la http and smtp (neither of  
which uses a size-of-headers for clients posting messages), though.

I completely agree on limiting line length and limiting headers -- it  
seems arbitrary, but allowing a max of N headers provides the same  
anti-DOS behavior, while still allowing for telnet clients.

-Brian

ps: forwarded this to the stomp discussion list as well, I very much  
appreciate your feedback, as you have very good points. Thank you for  
raising them =)

>
> Zed A. Shaw
> http://www.zedshaw.com/
>
>
> On Mon, 24 Oct 2005 12:41:51 +0900
> Brian McCallister <brianm / apache.org> wrote:
>
>
>> Zed,
>>
>> The \0 terminator is used if there is *not* a content-length header,
>> it is recommended that a content-length header be used. The primary
>> reason for this is that I *really* want to support telnet and netcat
>> for emergencies and debugging =)
>>
>> That said, please keep the criticism coming, I don't think for a
>> moment that I know everything, and the folks helping with stomp are
>> all merely trying to solve a problem, no one is pushing an agenda
>> (that I am aware of!).
>>
>> I would very much appreciate your further feedback!
>>
>> -Brian
>>
>> On Oct 23, 2005, at 8:31 PM, Zed A. Shaw wrote:
>>
>>
>>> I'm kind of in the process of writing something like this, but if
>>> you want take a look at STOMP and the following:
>>>
>>> http://stomp.codehaus.org/Ruby+Client
>>>
>>> STOMP will then let you talk with several different JMS
>>> implementations
>>> (mostly open source).
>>>
>>> Be careful though, STOMP isn't as well designed as I'd like.  For
>>> example, it uses \0 to end the message body, without any way of
>>> escaping the \0.  This means you have to base64 things you send if
>>> they
>>> have \0 characters.
>>>
>>> Zed A. Shaw
>>> http://www.zedshaw.com/
>>>
>>>
>>> On Mon, 24 Oct 2005 12:03:26 +0900
>>> swille <sillewille / gmail.com> wrote:
>>>
>>>
>>>
>>>> Err.. :) Can anyone tell me if there's a MOM for Ruby?  Anything
>>>> like JMS?  I haven't quite found one in my googling.
>>>>
>>>> Also, and this is a long-shot, is there possibly a workflow engine
>>>> that anyone has stuffed away?
>>>>
>>>>
>>>>
>>>
>>>
>>>
>>
>>
>>
>
>