[asterisk-bugs] [JIRA] (ASTERISK-26207) [patch] sRTP: Count a roll-over of the sequence number even on lost packets.

[Alexander Traud (JIRA)]

     [ https://issues.asterisk.org/jira/browse/ASTERISK-26207?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Alexander Traud updated ASTERISK-26207:
---------------------------------------

    Comment: was deleted

(was: Thanks for creating a report! The issue has entered the triage process. That means the issue will wait in this status until a Bug Marshal has an opportunity to review the issue. Once the issue has been reviewed you will receive comments regarding the next steps towards resolution.

A good first step is for you to review the [Asterisk Issue Guidelines|https://wiki.asterisk.org/wiki/display/AST/Asterisk+Issue+Guidelines] if you haven't already. The guidelines detail what is expected from an Asterisk issue report.

Then, if you are submitting a patch, please review the [Patch Contribution Process|https://wiki.asterisk.org/wiki/display/AST/Patch+Contribution+Process].)

> [patch] sRTP: Count a roll-over of the sequence number even on lost packets.
> ----------------------------------------------------------------------------
>
>                 Key: ASTERISK-26207
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-26207
>             Project: Asterisk
>          Issue Type: Bug
>      Security Level: None
>          Components: Resources/res_rtp_asterisk
>    Affects Versions: 11.22.0, 13.9.1
>            Reporter: Alexander Traud
>            Severity: Minor
>
> See the sRTP FAQ, [Question 6…|http://srtp.sourceforge.net/faq.html#Q6]
> With RTP media, each packet gets its own sequence number to detect lost  and late packets. That sequence number is limited to a value of {{0xffff}}. To avoid any replay-attacks, sRTP introduced a counter which is incremented whenever the sequence number rolls over (ROC). The ROC is not transmitted. Therefore, both sender and receiver must note each roll over of the sequence number.
> The initial sequence number is created randomly. However, when
> - that random value is near the maximum value *and*
> - the first RTP packets get lost (or arrive late),
> the receiver might not notice the roll-over of the sequence number. The receiver might think, the RTP sequence started at 0,1,2,3…. Consequently, the ROC is of the receiver is 0. The ROC of the sender is 1. Both parties lost ROC synchronization. Therefore, the receiver is not able to decrypt the sRTP packets anymore. No media is the result.
> The mentioned webpage therefore suggests: The SRTP sender should randomly select an initial sequence number that is between {{0x0000}} and {{0x7fff}}. The attached patch does this.



--
This message was sent by Atlassian JIRA
(v6.2#6252)