We have an issue with the SequenceNumbers in the AnsiC stack (and in the .NET stack too).

We fail to check them since ever. There is a check on the Request Ids of multiple chunk messages, but that is not enough, to avoid man-in-the-middle from replaying, re-ordering or dropping any message they want.

The current status is, the AnsiC stack starts sequence numbers at 51, counts till UInt32.MaxValue, rolls over to 0, and counts on.
The .NET stack starts at 1, and counts on, have not tested how they actually roll over. Both stacks obviosly do not check the received sequence numbers at all. If the connection is signed&encrypted, the sequence numbers are encrypted too, if the connection is signed, the sequence numbers are signed too.
So it is impossible for man-in-the middle to alter the sequence numbers.
But he could drop anything that he dont like to reach the server, and neither the server nor the client will know what is going on. The correct behavior would be to reset the connection if there is a gap in the sequence numbers.

Well, initially I thought a SequnenceNumber of 0 is somehow forbidden, but I do not find any place in the part 6, that says that. Nor do I find any information what to expect, how the sequence numbers start.

There is however the following sentence in part 6:

The SequenceNumber shall also monotonically increase for all Messages and shall not wrap around until it is greater than 4 294 966 271 (UInt32.MaxValue – 1 024). The first number after the wrap around shall be less than 1 024.

Well, I dont like this at all. It allows too many choice, and it is way too complicated. I do not like to implement the wrap over in the sending side in this way.

And this allows Mr. man-in-the-middle to drop up to 1024 messages before and 1024 messages after the wrap over, which is bad.

I will implement the checking to allow a jump in the sequence numbers anywhere from 4294966272..4294967295 => 0..1023. At all other times, the sequence numbers may not jump, or the connection gets closed.

Currently, I want to check that the first sequence number is 0..1023 too. But that is actually not explicitly specified.

But I want to change this in the future, to be more restrictive.

I think at some time in the future, the wrap around should only be accepted from 4294967295 => 0, everything else is due to Mr. man-in-the-middle.
And the initial SequenceNumber of a new connection must be 1, and nothing else.

(If secure-channel reconnection is ever implemented, then the sequence number must start at LastSequenceNumber+1..LastSequenceNumber+1023
Currently I do not see that ever happening.)

My suggestion would be that we recommend now to start the sent SequenceNumbers from 1 on connection, and roll over from 4294967295 => 0, which should be compatible with the current spec, and allow the initial received SequenceNumber between 0..1023 and allow for the roll over to happen as currently specified in part 6, for backward compatibility.

But be prepared, that this can become more restrictive in the next version of the spec.