Changes between Version 2 and Version 3 of Ticket #600


Ignore:
Timestamp:
Aug 26, 2008 10:21:43 AM (16 years ago)
Author:
bennylp
Comment:

Legend:

Unmodified
Added
Removed
Modified

  • Ticket #600 – Description

    v2 v3  
    55 The {{{srtp_unprotect()}}} may fail on the following scenarios: 
    66 1. UAC sent INVITE, and the INVITE forks to more than one UAS's, and the UAS's all send RTP to the UAC. In this case, it is expected that only RTP packets from one UAS will be successfully processed. 
    7  1. The SRTP keys have changed in re-INVITE/UPDATE, and the SRTP session has been re-created with the new keys, but some old RTP packets are still lingering in the network or in socket buffer. The SRTP then may learn it's initial state from these old packets. The old packets may have different properties than the new packets, e.g. SSRC or sequence number, and this will cause the new RTP packets to be rejected by the SRTP session. 
     7 1. The SRTP keys have changed in re-INVITE/UPDATE, and the SRTP session has been re-created with same keys, but some old RTP packets are still lingering in the network or in socket buffer. The SRTP then may learn it's initial state from these old packets. The new packet may have different sequence numbering than the old packets, and this will cause the new RTP packets to be rejected by the SRTP session. 
    88 1. Some attacker genuinely replays old SRTP packets 
     9 
     10 From the scenarios above, this ticket only handles the scenario no 2.  
     11 
     12'''Solution:''' 
     13 
     14 1. Modify the stream, so that when it's restarted it will maintain the sequence number and timestamp from the last transmission. 
     15 1. Modify SRTP transport, so that when it's restarted, it takes into consideration that some old packets may be received. This is to handle the case where the UA is talking to another UA that doesn't maintain sequence number during re-INVITE and UPDATE. 
     16