receiver
Click on the red underlined text to get to the source
... RFC3711] session, out-of-band
signaling must provide the receiver with the value of the ROC the
sender ...
... MIKEY [RFC3830] message. In some
cases, the receiver will not be able to synchronize his ROC with the
one used by the sender ...
... synchronization failure will appear are:
1. The receiver receives the ROC in a MIKEY message together with a
...
... ROC is used
as input in session key derivation. In either case, the receiver
will not have its ROC synchronized with the sender ...
... out-of-band signaling.
2. If the receiver leaves the session (due to being out of radio
coverage or because of a user action), and does not start ...
... traffic from the service again until after 2^15 packets
have been sent, the receiver will be out of synchronization (for
the same reasons as in example 1).
...
... the same reasons as in example 1).
3. The receiver joins a service when the SEQ has recently wrapped
...
... ROC = 1) in the MIKEY
message. The MIKEY message reaches the receiver, who reads the
ROC value and initializes its local ROC ...
... SEQ lower than 0 (say,
SEQ = 0xffff), was delayed and reaches the receiver as the first
SRTP packet he sees, the receiver ...
... receiver as the first
SRTP packet he sees, the receiver will initialize its highest
received sequence number, s_l, to 0xffff. Next, the receiver ...
... receiver will initialize its highest
received sequence number, s_l, to 0xffff. Next, the receiver will
receive SRTP packets with sequence numbers ...
... sequence numbers larger than zero, and
will deduce that the SEQ has wrapped. Hence, the receiver will
incorrectly update the ROC ...
... 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 may similarly end up out of synchronization.
...
... Master Key Identifier) field of each SRTP packet. This
has the advantage that the receiver immediately knows the entire
index for a packet. Unfortunately, the MKI has no semantics ...
... SRTP. Furthermore, when the
ROC is transmitted to the receiver it needs to be integrity protected
to avoid persistent denial-of-service ...
... DoS) attacks or transmission
errors that could bring the receiver out of synchronization. (A DoS
attack is regarded as persistent if it can last after the attacker ...
... possibility to use it sparsely.
When the receiver receives an SRTP packet, it processes the packet
according to RFC 3711prop ...
... integrity protection is to
be verified, if the SEQ is equal to 0 modulo R, the receiver extracts
ROC_sender ...
... sender instead of concatenated with the
local_ROC. The receiver generates MAC_tr for the MAC verification in
...
... consideration MUST be used. If the verification is successful, the
receiver sets his local ROC equal to the ROC carried in the packet.
...
... ROC from the packet in the MAC calculation is
that if the receiver has an incorrect ROC value, MAC verification
...
...
If the SEQ is not equal to 0 mod R, the receiver just proceeds to
process the packet according to RFC 3711prop without performing the
...
... In case no integrity protection is offered, i.e., mode 3, the
following applies. The receiver's SRTP layer SHOULD ignore the ROC
...
... 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.
...
... attacker modifies the ROC, the
modification will go undetected by the receiver, and the receiver
will lose cryptographic ...
... ROC, the
modification will go undetected by the receiver, and the receiver
will lose cryptographic synchronization ...
... ROC, and the ROC is modified by an
attacker (and the receiver already has an approximation of the ROC,
e.g., by getting it previously), the packet will be discarded and the
...
... ROC,
e.g., by getting it previously), the packet will be discarded and the
receiver will not be able to decrypt correctly. Note, however, that
the situation is better in the latter case, since the receiver now
...
... receiver will not be able to decrypt correctly. Note, however, that
the situation is better in the latter case, since the receiver now
can try different ROC values in a neighborhood ...