Subject: [hybi] FIN bit and opcode=0 (why rely on opcode=0 ??)

From: Iñaki Baz Castillo <[email-masked]>
Date: Mon, 15 Aug 2011 15:26:31 +0200

Hi, I don't like the mechanism to tell whether a fragment is a single
message or a continuation. Basically it works as follows (a
combination of two bits):

- frame 1:   FIN=0, opcode=1  (text message)
- frame 2:   FIN=0, opcode=0  (continuation)
- frame 3:   FIN=1, opcode=0  (continuation)

This is a message spitted in 3 frames.

Unfortunatelly having to set opcode=0 is useless (if I'm not wrong)
and leaves the door open to ugly cases, for example, how should the
server react on the following cases?:

case 1)

- frame 1:   FIN=0, opcode=1  (text message)
- frame 2:   FIN=0, opcode=1  (text message)

case 2)

- frame 1:   FIN=0, opcode=1  (text message)
- frame 2:   FIN=1, opcode=1  (text message)

case 3)

- frame 1:   FIN=0, opcode=0  (continuation)

case 4)

- frame 1:   FIN=1, opcode=0  (continuation)

Frames belonging to the same message must be sequential so, wouldn't
be much easier to drop "opcode=0" (continuation) and just use the FIN
bit?
Then the opcode is just inspected by the server in the first frame. If
such frame has FIN=0 then opcode is not inspected in next frames of
the same message.

So:

- frame 1:   FIN=0, opcode=1  (text message)
- frame 2:   FIN=0, opcode=X  (it does not matter)
- frame 3:   FIN=1, opcode=X  (it does not matter)

This would make much more easy ugly cases described below.

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: John Tamplin <[email-masked]>
Date: Mon, 15 Aug 2011 10:20:51 -0400

> This would make much more easy ugly cases described below.

The value must be set to something, so allowing it to be set arbitrarily
seems ripe for errors -- for example, one implementation always uses the
opcode of the last frame when delivering the message, and another using the
first.  Attackers use similar problems in how browsers interpret things
today, and it seems prudent to avoid it by defining the continuation opcode.

-- 
John A. Tamplin
Software Engineer (GWT), Google

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Mon, 15 Aug 2011 16:23:43 +0200

> today, and it seems prudent to avoid it by defining the continuation opcode.

Ok, so just make opcode to be constant within frames of the same message:

- frame 1:   FIN=0, opcode=1  (text message)
- frame 2:   FIN=0, opcode=1
- frame 3:   FIN=1, opcode=1

But the point here is that the server does NOT need to inspect opcode
for frames after the first one.

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: Tobias Oberstein <[email-masked]>
Date: Mon, 15 Aug 2011 07:30:03 -0700

> Unfortunatelly having to set opcode=0 is useless (if I'm not wrong) and
> leaves the door open to ugly cases, for example, how should the server react
> on the following cases?:

The connection should be immediately failed. This is not required by the spec,
while IMHO the spec should require that a MUST.

> - frame 1:   FIN=1, opcode=0  (continuation)

All cases are tested in a little test suite I wrote .. see cases 5.x

http://www.tavendo.de/autobahn/testsuite/report/

Firefox Nightly has all cases correct and fails the connection immediately.

My implementation fails the connection with 2 errors for the cases above

"received continuation data frame outside fragmented message"
"received non-continuation data frame while inside fragmented message"

> Frames belonging to the same message must be sequential so, wouldn't be
> much easier to drop "opcode=0" (continuation) and just use the FIN bit?
> Then the opcode is just inspected by the server in the first frame. If such
> frame has FIN=0 then opcode is not inspected in next frames of the same
> message.
> 
> So:
> 

You can't have X arbitrary, since there can be interleaved (unfragmented) control messages.

So X could only be a data frame opcode.
 
But then, saying X could be anything (because you don't interpret it) doesn't make things
easier. You remove protocol violations for introducing protocol variance. Implementations
will chose different X. One may choose the X = Opcode of first. One may choose X = some
fixed data opcode.

Moreoever, what about intermediaries?

Instead, IMHO there are 3 things mixed up:

FIN
an Opcode for continuation
Opcodes for payload _types_

There should have been no distinction into text/binary payloads, and then
there would be no need for continuation opcode, but only FIN and 1 opcode for
data (to distinguish from control).

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Mon, 15 Aug 2011 16:33:03 +0200

> will chose different X. One may choose the X = Opcode of first. One may choose X = some

Ok, I've already replied in other mail that instead of "any opcode",
mandate that all the frames have the same opcode as the first one. But
there is no need at all for the opcode=0 (continuation) value, as its
meaning is already given by the FIN bit.

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: Tobias Oberstein <[email-masked]>
Date: Mon, 15 Aug 2011 07:40:22 -0700

> > But then, saying X could be anything (because you don't interpret it)
> > doesn't make things easier. You remove protocol violations for
> > introducing protocol variance. Implementations will chose different X.
> > One may choose the X = Opcode of first. One may choose X = some fixed
> data opcode.
> 
> Ok, I've already replied in other mail that instead of "any opcode", mandate
> that all the frames have the same opcode as the first one. But there is no
> need at all for the opcode=0 (continuation) value, as its meaning is already
> given by the FIN bit.

Yes, but "mandate" means it could be violated, therefor you need to check
in implementations anyway.

For example, whether the check is

"opcode == 0" or "opcode == opcode of 1st fragment"

when inside fragmented message seems to make no difference.

---

From: Joe Mason <[email-masked]>
Date: Mon, 15 Aug 2011 13:25:46 -0400

> for frames after the first one.

The server always needs to check the opcode to look for control messages embedded in a fragmented message.

Requiring the opcode to be 0 lets us detect the case where a client tries to interleave fragmented data messages (which is disallowed), or fails to send a FIN for one message, and fail the connection immediately.  If we reuse the same opcode there's no way to distinguish frame 1 of a new message from frame 2 of the current message, so we must assume that the client is doing everything perfectly.

Joe

---------------------------------------------------------------------
This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Mon, 15 Aug 2011 19:30:19 +0200

> The server always needs to check the opcode to look for control messages embedded in a fragmented message.

Do I miss something? that is forbidden. Control frames must have FIN=1
and opcode != 0.

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: Joe Mason <[email-masked]>
Date: Mon, 15 Aug 2011 13:33:26 -0400

Yes, if a client sends a control opcode with FIN=0, this is also an error.  So if the server did not read the opcode, it would never detect this error.

> -----Original Message-----
> From: Iñaki Baz Castillo [mailto:[email-masked]]
> Sent: Monday, August 15, 2011 1:30 PM
> To: Joe Mason
> Cc: John Tamplin; [email-masked]
> Subject: Re: [hybi] FIN bit and opcode=0 (why rely on opcode=0 ??)
> 
> > The server always needs to check the opcode to look for control
> messages embedded in a fragmented message.
>