is this "broken"?

[der Mouse <mouse%Rodents.Montreal.QC.CA@localhost>]

I've just run into behaviour from a vendor appliance (which I would
prefer not to name now because I'd rather give them a chance to fix it
before embarrassing them even semi-publicly) which seems rather broken
to me.  The RFCs aren't explicit about this, but it seems to me that
their silence supports my position; I wanted to get the opinions of the
people here before getting *tooo* upset at them.

When I use my ssh implementation to connect without any particular
options, I get a protocol-error disconnect.  If I turn on packet data
logging, I find that my initial kex packet provokes

158  In data (29):
159     0   01 00 00 00 02 00 00 00  10 50 72 6f 74 6f 63 6f  ·········Protoco
160    10   6c 20 54 69 6d 65 6f 75  74 00 00 00 00           l Timeout····

which seems bizarre.  If I don't use my implementation's packet
logging, but instead snoop the network traffic, I see:

My client -> their server
TCP packet containing my banner and the beginning of my first kex
packet.  (My kex packet's length is 0x9bc, with 6 bytes of padding.)

My client -> their server
TCP packet containing the rest of my first kex packet.

Their server -> my client
TCP packet containing their banner and an ACK for my first packet.

Their server -> my client
TCP packet containing their first kex packet and an SSH_MSG_DISCONNECT
with reason code SSH_DISCONNECT_PROTOCOL_ERROR, text "Bad packet
length", and a zero-length language tag.

(Then follows routine connection teardown.)

Their kex offers only one cipher (3des-cbc); when I tell my
implementation to offer only that cipher, bringing my kex packet length
down to 0x1c7, it gets past this point (regardless of whether I have
packet logging on or off).  Then, kex succeeds and it accepts my "none"
userauth (this is normal given how it's configured), but fails later:

(-> is me-to-them; <- is them-to-me.)
-> KEXINIT
<- KEXINIT
-> KEXDH_INIT
<- KEXDH_REPLY
-> NEWKEYS
<- NEWKEYS
-> SERVICE_REQUEST, ssh-userauth
<- SERVICE_ACCEPT, ssh-userauth
-> USERAUTH_REQUEST, mouse/ssh-connection/none
<- USERAUTH_BANNER
<- USERAUTH_SUCCESS
-> CHANNEL_OPEN, session, max packet size 0x88ab
<- CHANNEL_OPEN_CONFIRMATION, max packet size 0x400
-> CHANNEL_REQUEST, fixed-auth-agent-req-2%rodents.montreal.qc.ca@localhost, want-reply=true
-> CHANNEL_REQUEST, fixed-x11-req-2%rodents.montreal.qc.ca@localhost, want-reply=true
<- DISCONNECT, SSH_DISCONNECT_PROTOCOL_ERROR, "Bad string Length"

If I use the flags to disable agent and X forwarding, instead I get

...
-> CHANNEL_OPEN, session, max packet size 0x88ab
<- CHANNEL_OPEN_CONFIRMATION, max packet size 0x400
-> CHANNEL_REQUEST, pty-req, want-reply=true
-> CHANNEL_REQUEST, missing-pty-modes%rodents.montreal.qc.ca@localhost, want-reply=false
<- CHANNEL_SUCCESS
-> CHANNEL_REQUEST, shell, want-reply=true
<- DISCONNECT, SSH_DISCONNECT_PROTOCOL_ERROR, "Bad string Length"

So it appears to me that this implementation does not understand my
private requests, which is not a surprise, but is also sufficiently
stupid that a request name longer than it's prepared for is considered
a protocol error rather than being treated as an unrecognized request.

So, my question to this august assemblage is, would you call this
outright *broken*, or just *ahem* a low-quality implementation?  It
certainly does seem to me that their limit on request name length is
unreasonably low, sufficiently so that I'd call it busted - but that
could just be my bias speaking.  (I also see the "Protocol Timeout"
error as..odd, at the very least.)

I don't see anything in the RFCs indicating any expectation of a limit
on request name lengths - but of course any implementation with less
than gigabytes of storage must have one, since the protocol supports
string lengths up to 0x7fffffff and probably up to 0xffffffff (I
haven't checked whether string lengths are signed, since for the
purpose at hand here it doesn't matter).  So I'm not sure, but this
reaction to a request name this short seems to me to fall in "broken"
territory.

/~\ The ASCII				der Mouse
\ / Ribbon Campaign
 X  Against HTML	       mouse%rodents.montreal.qc.ca@localhost
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B