RFC 4771:Integrity Transform Carrying Roll-Over Co...
RFC-Ref

sender


Click on the red underlined text to get to the source

... receiver with the value of the ROC the sender is currently using. For instance, it can be transferred in the Common Header Payload ...
... receiver will not be able to synchronize his ROC with the one used by the sender, even if it is signaled to him out of band. Examples of where synchronization failure will appear are: ...
... join the service until after a few hours, at which point the sender's sequence number (SEQ) has wrapped around, and so the ...
... sequence number (SEQ) has wrapped around, and so the sender, meanwhile, has increased the value of ROC. When the user joins the service ...
... receiver will not have its ROC synchronized with the sender, and it is not possible to recover without out-of-band signaling. ...
... SEQ has recently wrapped around (say, SEQ = 0x0001). The sender generates a MIKEY message and includes the current value of ROC ...
... 4. Similarly to (3), since the initial SEQ is selected at random by the sender, it may happen to be selected as a value very close to 0xffff. In this case, should the first few packets be lost, the receiver ...


... RCC for short), works as follows. The sender processes the RTP packet according to RFC 3711prop. When ...
... 3711prop. When applying the message integrity transform, the sender checks if the SEQ is equal to 0 modulo some non-zero ...
... non-zero integer constant R. If that is the case, the sender computes the MAC in the same way as is done when using the default integrity transform ...
... Authenticated_portion || ROC)). Next, the sender truncates the MAC by 32 bits ...
... most significant bits of the MAC. Next, the sender constructs the tag as TAG ...
... tag as TAG = ROC_sender || MAC_tr, where ROC_sender ...
... sender || MAC_tr, where ROC_sender is the value of his local ROC, and appends the tag ...
... If the SEQ is not equal to 0 mod R, the sender just proceeds to process the packet according to RFC 3711prop without performing the ...
... ROC_local is replaced by ROC_sender (retrieved from the packet). This works as follows. In the step where integrity protection is to ...
... receiver extracts ROC_sender from the TAG and verifies the MAC computed (in the same ...
... RFC3711]), but concatenated with ROC_sender instead of concatenated with the local_ROC. The receiver ...
... MAC_tr for the MAC verification in the same way the sender did. Note that the session key used in the MAC calculation ...


... application layer can indicate to it that the local ROC is synchronized with the sender (hence, the packet would be processed using the local ROC). Note that the received ROC ...


... integrity protected in mode 1, so unless R = 1, the mechanism should be seen for what it is: a way to improve sender-receiver synchronization, and not a replacement for integrity protection ...



Google
Web
RFC-Ref