View Issue Details
ID | Project | Category | View Status | Date Submitted | Last Update |
---|---|---|---|---|---|
0003256 | UA | Implementation Bug | public | 2015-12-18 13:25 | 2016-05-04 07:16 |
Reporter | Bernd Edlinger | Assigned To | |||
Priority | normal | Severity | minor | Reproducibility | always |
Status | resolved | Resolution | fixed | ||
Summary | 0003256: SequenceNumbers not checked by the Stack | ||||
Description | 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. 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. (If secure-channel reconnection is ever implemented, then the sequence number must start at LastSequenceNumber+1..LastSequenceNumber+1023 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. | ||||
Tags | No tags attached. | ||||
Fix Due Date | |||||
|
to reproduce you can change but but if we skip sequence numbers, i.e. perform ++ twice: |
|
fixed in 1.03.340. |
Date Modified | Username | Field | Change |
---|---|---|---|
2015-12-18 13:25 | Bernd Edlinger | New Issue | |
2015-12-21 11:39 | Bernd Edlinger | Note Added: 0006474 | |
2016-05-04 07:15 |
|
Assigned To | => user319 |
2016-05-04 07:15 |
|
Status | new => acknowledged |
2016-05-04 07:16 |
|
Note Added: 0006858 | |
2016-05-04 07:16 |
|
Status | acknowledged => resolved |
2016-05-04 07:16 |
|
Resolution | open => fixed |