[treflop]

From my experience, almost no protocols have in-band signaling. No protocol I’ve ever built has in-band signaling because it’s nuts.

You always know what the next byte means because either you did a prefixed length, your protocol has stringent escaping rules, or you chose an obvious and consistent terminator like null.

[yencabulator]

SMTP has stringent escaping rules. The authors of the code in the article were incompetent.

[pja]

If your metadata about the data is in the same channel as the data then you’re doing in-band signalling.

[treflop]

Not in modern times.

The terms harken back from the day of circuit switched networks but now that we have heavily transitioned to packets, bands are an artificial construct on top of packets and applying the term isn’t very clear cut.

The main property of in-band data in the circuit-switched network days is that you could inject commands into your data stream. If we apply that criteria that to a modern protocol, even if you mix metadata and data in the same “band,” if your data can never be interpreted as commands then “out of band” makes an apt description.

See https://en.m.wikipedia.org/wiki/Out-of-band_data

[TeMPOraL]

That's only true if you're not breaking the protocol abstraction layer. There is no "out-of-band" once you serialize your messages. If you start injecting random bytes into the data stream on the wire, you can absolutely start introducing commands, or confuse the receiver where the next piece of metadata/control is.

In this case, somewhere the protocol abstraction layer got broken, and the message text ended up being treated as already serialized. It's not a problem with the protocol per se, but with bad implementation of its API (or no implementation at all, just printf-ing into the wire format).

[treflop]

Injecting random data into any protocol will break it.

When we’re talking about whether someone can inject data into the link, we’re talking about the end user and not the software. If we’re talking protocol design, then you wouldn’t want regular data to be able to inject commands by simply existing.

[TeMPOraL]

> Injecting random data into any protocol will break it.

It shouldn't, unless you're bypassing the actual protocol serialization layer (or hitting a bug in the implementation). Which is what's the case here. Protocol design can't address the case of users just writing out some bytes and declaring it's a valid protocol message.

[treflop]

Sure but I’m not replying to the thread.

I’m replying to a post where someone said most protocols have in-band signaling and therefore this problem is unavoidable.