| Summary: | ASTERISK-29519: ROC value not incremented in SRTP | ||
| Reporter: | Marcos Cereijo RodrÃguez (mcereijo) | Labels: | patch |
| Date Opened: | 2021-07-13 02:34:57 | Date Closed: | 2021-07-27 12:00:04 |
| Priority: | Minor | Regression? | |
| Status: | Closed/Complete | Components: | Resources/res_srtp |
| Versions: | 18.4.0 | Frequency of Occurrence | Constant |
| Related Issues: | |||
| Environment: | Attachments: | ( 0) srtp_auth_tag.patch | |
| Description: | 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> | ||
| Comments: | By: Asterisk Team (asteriskteam) 2021-07-13 02:35:00.940-0500 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. Please note that log messages and other files should not be sent to the Sangoma Asterisk Team unless explicitly asked for. All files should be placed on this issue in a sanitized fashion as needed. 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]. Please note that once your issue enters an open state it has been accepted. As Asterisk is an open source project there is no guarantee or timeframe on when your issue will be looked into. If you need expedient resolution you will need to find and pay a suitable developer. Asking for an update on your issue will not yield any progress on it and will not result in a response. All updates are posted to the issue when they occur. Please note that by submitting data, code, or documentation to Sangoma through JIRA, you accept the Terms of Use present at [https://www.asterisk.org/terms-of-use/|https://www.asterisk.org/terms-of-use/]. By: Joshua C. Colp (jcolp) 2021-07-13 03:52:38.847-0500 In order to contribute code you will need to sign the license agreement and attach the change. By: Asterisk Team (asteriskteam) 2021-07-27 12:00:03.803-0500 Suspended due to lack of activity. This issue will be automatically re-opened if the reporter posts a comment. If you are not the reporter and would like this re-opened please create a new issue instead. If the new issue is related to this one a link will be created during the triage process. Further information on issue tracker usage can be found in the Asterisk Issue Guidlines [1]. [1] https://wiki.asterisk.org/wiki/display/AST/Asterisk+Issue+Guidelines By: Alexander Traud (traud) 2021-09-17 06:28:23.564-0500 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. | ||