The security header is always followed by the sequence header which is defined in Table 56. The sequence header ensures that the first encrypted block of every Message sent over a channel will start with different data.
|
Name |
Data Type |
Description |
|
SequenceNumber |
UInt32 |
A monotonically increasing sequence number assigned by the sender to each MessageChunk sent over the SecureChannel. |
|
RequestId |
UInt32 |
An identifier assigned by the Client to OPC UA request Message. All MessageChunks for the request and the associated response use the same identifier. |
A SequenceNumber may not be reused for any TokenId. The SecurityToken lifetime shall be short enough to ensure that this never happens; however, if it does the receiver shall treat it as a transport error and force a reconnect. The SequenceNumber does not reset when a new TokenId is issued and it shall be incremented by exactly one for each MessageChunk sent.
SecurityPolicies with LegacySequenceNumbers set to TRUE, the SequenceNumber shall 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.
SecurityPolicies with LegacySequenceNumbers set to FALSE, the SequenceNumber shall start at 0 and monotonically increase for all Messages and shall not wrap around until it is equal to 4 294 967 295 (UInt32.MaxValue). The first number after the wrap around shall be 0.
Some applications will find it takes time to validate the OpenSecureChannel Requests and Responses used to renew a TokenId. In these situations, the receiver may assume the SequenceNumber is correct which allows it to process subsequent messages secured with the existing TokenId before the OpenSecureChannel Message is validated. When processing of the OpenSecureChannel Message completes, the receiver checks the SequenceNumber and closes the SecureChannel if it is incorrect.
The sequence header is followed by the Message body which is encoded with the OPC UA Binary encoding as described in 5.2.9. The body may be split across multiple MessageChunks.