Control SDES cipher suites in answer

[Alex Balashov]

Hi,

For problematic endpoints that do not support all the cipher suites they advertise, the various SDES flags, such as SDES-only-, SDES-no, etc. provide excellent solutions, as long as the control is in the offer going toward SRTP endpoints. It seems, from the documentation and the commit messages, that all this is intended to control what is in the offer.

However, the problem I have, in this case, is with outbound calls from an SRTP endpoint, across RTPEngine performing SRTP->plain UDP bridging functions.

The endpoint offers:

a=crypto:1 AEAD_AES_128_GCM inline:xxx
a=crypto:2 AES_CM_128_HMAC_SHA1_80 inline:xx
a=crypto:3 AEAD_AES_256_GCM inline:xxx
a=crypto:4 AES_256_CM_HMAC_SHA1_80 inline:xxx

But cannot actually support all of these, in spite of what it offers. Accordingly, in the SDP answer from RTPEngine, we negotiate down to:

a=crypto:1 AEAD_AES_128_GCM inline:xxx

The endpoint (Linphone) is defective and cannot decipher AEAD_AES_128_GCM, in spite of advertising it.

It seems to me, however, that there ought to be a way to make the Linphone caller and RTPEngine agree on AES_CM_128_HMAC_SHA1_80. I have tried two things:

1) Calling rtpengine_offer() with these flags (RFC 4568 enumerated ciphers):

SDES-only-AES_CM_128_HMAC_SHA1_80 SDES-only-AES_CM_128_HMAC_SHA1_32 SDES-only-F8_128_HMAC_SHA1_80 RTP/AVP

This is with the knowledge that these parameters will be discarded because the offer will be stepped down to UDP, but the hope was that they would influence what is isomorphically returned in the answer to the other side.

2) Calling rtpengine_answer() with these flags:

SDES-only-AES_CM_128_HMAC_SHA1_80 SDES-only-AES_CM_128_HMAC_SHA1_32 SDES-only-F8_128_HMAC_SHA1_80 RTP/SAVP

Somewhat counterintuitively, the latter seems to have no effect. It would seem that the acceptable ciphers are set in stone in the offer processing, but not if the incoming SRTP offer is replaced with a plain-RTP one.

So, the question is: is there a way to constrain which cipher suites are offered in the SDP answer generated by RTPEngine?

Many thanks in advance!

-- Alex

--
Alex Balashov
Principal Consultant
Evariste Systems LLC
Web: https://evaristesys.com
Tel: +1-706-510-6800

[Richard Fuchs]

On 24/06/2024 17.24, Alex Balashov wrote:

So, the question is: is there a way to constrain which cipher suites are offered in the SDP answer generated by RTPEngine?

I think you're looking for the `SDES-offerer_pref:...` option. It doesn't let you ignore or reject specific cipher suites, but it lets you prefer certain ones over others. If you tell it to prefer the AES suites then you should get the desired result.

Cheers

[Alex Balashov]

Thanks, Richard! Really appreciate that.

There are some really stupid endpoints out there.

> --
> You received this message because you are subscribed to the Google Groups "Sipwise rtpengine" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to rtpengine+...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/rtpengine/b2367f52-d9de-4014-a5d9-092e66471244%40sipwise.com.

[Alex Balashov]

Hi Richard,

Thank you for your suggestion, but unfortunately it did not work. The offer from the SRTP endpoint (forwarded on to plain UDP endpoint):

a=crypto:1 AEAD_AES_128_GCM inline:61UbxZESE5gv5ifvTSNU5Rjp/lAAlkrhubVyZQ==
a=crypto:2 AES_CM_128_HMAC_SHA1_80 inline:utaTGoGagxZReHbHdBqFO9Gc1rYPvb8OW8HGt4wx
a=crypto:3 AEAD_AES_256_GCM inline:WBKeFqOMvzfSuTJOBL44SOwiy7Iiusi3BYyM0erQqTRMr+bJRgOQqap7Uw0=
a=crypto:4 AES_256_CM_HMAC_SHA1_80 inline:kGYghfTxsCllnbnO9Xu6rMAKiFAgcqz1cvLMPJ1vunlMONi5pfwML2deQrO4GQ==

And the answer that goes back to the SRTP endpoint is still:

a=crypto:1 AEAD_AES_128_GCM inline:6OytrW9wg/mxWIgxPzaGPKOmmK6rt/CESO24JA

This is with the following SDES-offerer_pref value and mr11.5.1.9.

$var(workaround_ciphers_opref) = 'SDES-offerer_pref:AES_CM_128_HMAC_SHA1_80;AES_CM_128_HMAC_SHA1_32;';

I can confirm that this flag and its value are in the offer and answer command on the wire.

I should say that I am also sending these flags:

SDES-only-AES_CM_128_HMAC_SHA1_80 SDES-only-AES_CM_128_HMAC_SHA1_32 SDES-only-F8_128_HMAC_SHA1_80

However, nothing that you said, or the documentation, leads me to believe SDES-only-X and SDES-offerer_pref:[...] are mutually exclusive. Are they?

-- Alex

> On Jun 25, 2024, at 8:18 AM, 'Richard Fuchs' via Sipwise rtpengine <rtpe...@googlegroups.com> wrote:
>

> --
> You received this message because you are subscribed to the Google Groups "Sipwise rtpengine" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to rtpengine+...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/rtpengine/b2367f52-d9de-4014-a5d9-092e66471244%40sipwise.com.

[Alex Balashov]

Richard,

In fact, one gets the impression that, in mr11.5.1.9 at least, SDES-only options have no influence on the answer if the bridging destination is of the RTP/AVP profile, while SDES-no options do.

If I remove the SDES-offerer_pref options entirely and simply suppress the AEAD ciphers with:

rtpengine_manage("... SDES-no-AEAD_AES_128_GCM SDES-no-AEAD_AES_256_GCM RTP/AVP");

Then from an offer like this:

a=crypto:1 AEAD_AES_128_GCM inline:hWBpIntJt5mQsNUDtAbzx0v0E0Ihp4zNvfxnWw==
a=crypto:2 AES_CM_128_HMAC_SHA1_80 inline:jkIUsmkSJyktY7fSQOnQmiLO9LbVL5OKWmCKbcor
a=crypto:3 AEAD_AES_256_GCM inline:3etwU4ekk1Zxh2q9qUb2IT2JdvhDR4FyxYoX01Jrh1wWHpVijciciD55w+8=
a=crypto:4 AES_256_CM_HMAC_SHA1_80 inline:EjvGIpdNg5ThXz3G6mG2uqiOFr/tsg6D/VkKjK/6nm1ATQafFgPI9vo720RX9g==

We negotiate an answer down to:

a=crypto:2 AES_CM_128_HMAC_SHA1_80 inline:aC25RnCsgyTLvLU9gkvZ3Xrzpu6LIjr36hb8rVb2

However, if I use this:

rtpengine_manage("... SDES-only-AES_CM_128_HMAC_SHA1_80 SDES-only-AES_CM_128_HMAC_SHA1_32 SDES-only-F8_128_HMAC_SHA1_80");

it seems to have no effect on the answer whatsoever:

a=crypto:1 AEAD_AES_128_GCM inline:02XBAkXjYMP9Zs5j8XQKF3vVrbC87gcE+kPaBw

And this is true regardless of whether I also have a SDES-offerer_pref list set.

-- Alex

> On Jun 25, 2024, at 8:18 AM, 'Richard Fuchs' via Sipwise rtpengine <rtpe...@googlegroups.com> wrote:
>

> --
> You received this message because you are subscribed to the Google Groups "Sipwise rtpengine" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to rtpengine+...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/rtpengine/b2367f52-d9de-4014-a5d9-092e66471244%40sipwise.com.

[Richard Fuchs]

On 25/06/2024 18.28, Alex Balashov wrote:

I should say that I am also sending these flags:

SDES-only-AES_CM_128_HMAC_SHA1_80 SDES-only-AES_CM_128_HMAC_SHA1_32 SDES-only-F8_128_HMAC_SHA1_80

However, nothing that you said, or the documentation, leads me to believe SDES-only-X and SDES-offerer_pref:[...] are mutually exclusive. Are they?

No they're not, and in fact this combination is explicitly covered by one of the test cases (although in an SRTP <> SRTP scenario).

In fact, one gets the impression that, in mr11.5.1.9 at least, SDES-only options have no influence on the answer if the bridging destination is of the RTP/AVP profile, while SDES-no options do.

`SDES-only-...` and `SDES-no-...` are meant to influence cipher suites being *offered to* an SRTP endpoint (whether coming from a plain RTP or SRTP offer). They're not meant to influence what suites are being accepted from one. So you shouldn't expect any particular behaviour here, and in fact you probably should omit these options altogether when making an offer to a plain RTP endpoint.

Cheers

[Alex Balashov]

> On Jun 26, 2024, at 8:35 AM, 'Richard Fuchs' via Sipwise rtpengine <rtpe...@googlegroups.com> wrote:
>

>
>> In fact, one gets the impression that, in mr11.5.1.9 at least, SDES-only options have no influence on the answer if the bridging destination is of the RTP/AVP profile, while SDES-no options do.
>>
> `SDES-only-...` and `SDES-no-...` are meant to influence cipher suites being *offered to* an SRTP endpoint (whether coming from a plain RTP or SRTP offer). They're not meant to influence what suites are being accepted from one. So you shouldn't expect any particular behaviour here, and in fact you probably should omit these options altogether when making an offer to a plain RTP endpoint.

Understood, and this makes sense, given the focus of RTPEngine on bridging RTP from A to B. That's why there exist all of these ornate options for how to tailor the offer in the forward direction, while the thinking behind how to generate the answer is mostly, "Well, just reverse the adaptations in the offer, more or less."

Well, what I'm left with is a caller that is lying about the ciphers it supports. It advertises 4 suites but can actually only handle 2 of them, and the ones it can handle are neither at the top nor at the bottom of the priority list.

This problem only came about once we upgraded OpenSSL, and it was quite a significant long jump, though I don't remember the exact original version. I would guess that before the upgrade, the AEAD and 256-bit AES ciphers that the endpoint lies about supporting weren't supported on the RTPEngine side, either, so it wasn't a problem.

I'm thinking the best way to handle this might be to adulterate the SDP offer fed into RTPEngine, using the `read_sdp_pv` feature of the Kamailio NG control module. We can strip out the undesirable ciphers that aren't "actually" supported, and hopefully that will put the matter to bed. However, if you can think of any simpler solutions, I would appreciate any advice.

-- Alex

[Richard Fuchs]

On 26/06/2024 08.40, Alex Balashov wrote:

I'm thinking the best way to handle this might be to adulterate the SDP offer fed into RTPEngine, using the `read_sdp_pv` feature of the Kamailio NG control module. We can strip out the undesirable ciphers that aren't "actually" supported, and hopefully that will put the matter to bed. However, if you can think of any simpler solutions, I would appreciate any advice. 

SDES-offerer_pref is supposed to handle this, but clearly there's something missing. None of the test cases actually cover the SRTP<>RTP scenario, so it's very likely that there's a code path that simply doesn't take that option into account. I'll see if I can find the culprit.

Cheers

[Richard Fuchs]

Latest master contains a fix for this (commits db7315b3...d0fd696 in particular). Feel free to test it if you can. I think it's eligible for a backport as well.

Also see if perhaps https://groups.google.com/g/rtpengine/c/rA3yCIQIEn8/m/kbVIZCKJAAAJ is relevant to your troubles with Linphone.

Cheers