[asterisk-bugs] [JIRA] (ASTERISK-29519) ROC value not incremented in SRTP

[Alexander Traud (JIRA)]

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

Alexander Traud updated ASTERISK-29519:
---------------------------------------

    Attachment: srtp_auth_tag.patch

Attached is a patch, which does it the other way around. I am using that to test whether a phone does sRTP authentication. In the first seconds, the roll-over-counter is zero. For the next two seconds, the roll-over-counter is one. For the next four seconds, the authentication tag is intentionally damaged. You can use that with one of the various demo core/extra sound files. If you still hear the demo sound, the remote party does not check the sRTP authentication tag.

As stated, this is the other way around. Here, it is proof that Asterisk increments the roll-over-counter correctly. I went back and tested the patch with Asterisk 18.4.0, and it works as expected.

[~mcereijo], I believe you and your analysis. However, I am not able to reproduce your issue yet. Even if you sign the license agreement, your proposed patch is not going to be accepted in its current form. libSRTP handles the ROC automatically for its API users. That was the reason that [new API|https://github.com/cisco/libsrtp/commit/7af219a] existed not before libSRTP 2.1.

Long story short: What is your setup and call scenario:
# Are you using the channel driver {{chan_pjsip}}, or {{chan_sip}}?
# Are you using DTLS-sRTP, or SDES-sRTP?
# Does Asterisk start the call, or does Asterisk receive the call?
# Are you using the default of direct media = on, or off?

I am very interested in you issue because it sounds there is a call scenario which does not work as intended. I would love to take over and find the correct fix. However, for that, I have to reproduce your issue first.

> ROC value not incremented in SRTP
> ---------------------------------
>
>                 Key: ASTERISK-29519
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-29519
>             Project: Asterisk
>          Issue Type: Bug
>      Security Level: None
>          Components: Resources/res_srtp
>    Affects Versions: 18.4.0
>            Reporter: Marcos Cereijo Rodríguez
>              Labels: patch
>         Attachments: srtp_auth_tag.patch
>
>
> h3. What is happening?
> We have to do an integration with a client that wants to secure their communications with TLS for the signaling and SRTP for the media.
> After enabling SRTP all looked great, but the client detected that after ~22 minutes the call hangup automatically.
> After some debugging, the client inform us that his SBC provider detected the issue. The reason of this problem was that after the RTP sequence number overflowed, the ROC (roll-over counter) value wasn't increased.
> h3. Proposed solution
> We had to update the `libsrtp` version from 2.0.0 to 2.3.0. The reason for this change is that the default version included in Debian doesn't expose the headers from reading and changing the values of ROC.
> For implementing this, we modified the following files:
> * res/res_rtp_asterisk.c
> * res/res_srtp.c
> The modifications for *res_srtp.c*:
> <inline code removed>



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